InfoQは先日，2nd Watchの創業者でCTOのKris Bliesner氏と話をする機会を得た。氏は，従来型ITからクラウドへのマイグレーション作業に関して，深い経験を持っている。会話の中で氏は，クラウドへの作業移行に伴う一般的な問題を指摘し，推奨されるプロセスについて論じるとともに，セキュリティやコンプライアンス，DevOps，オートメーションといった話題についても意見を述べてくれた。
InfoQ: 今日はInfoQのために時間を頂いてありがとうございます。簡単な自己紹介と，ご自身のビジネスについて説明して頂けますか？
Bliesner: こんにちは，2nd WatchのCTOで共同創業者のKris Bliesnerです。当社はAWSプレミアコンサルティングパートナです。私たちのAWSクラウドサービスは，私たちの方法論や専門知識，ツールの提供とも合わせて，企業のパブリッククラウド活用を支援しています。さらに，AWSマネージドサービスパートナとして，ワークロードの移行サービスも提供します。その他にも，課金やパフォーマンス監視，セキュリティ，コンプライアンスといったマネージドクラウドサービスを提供しています。
InfoQ: 多数の企業に対して，ビジネスワークロードのクラウド移行を支援しているということですが，そのプロセスにおいて，最も一般的な課題をあげて説明して頂けますか？それらを克服した方法についても，簡単に説明をお願いします。
Bliesner: 問題は組織によってさまざまですが，その中で分かったのは，ほとんどの企業が，自分たちの所有しているものを十分に知らない，ということです。知っていると思っているかも知れませんが，変更を十分に追跡できていません。ですから，変更管理が課題です。私たちは毎回，クライアントと共に正確な評価を実施して，彼らのアプリケーションやリソースを理解するようにしています。これによって，私たちがこれから行うことを理解していて，何も見落とすことがないという，クライアントの信頼を得られます。もうひとつの問題は，大規模なデータセットの移行です。先日もある企業で，16PBを越えるデータの移行計画の評価を行ったばかりです。これほど大規模なデータを合理的な時間内に移動するのは，極めて困難な作業ですが，AWS Snowballを使用すれば，かなり速く実行できるのではないかと思っています。
InfoQ: セキュリティやガバナンス，コンプライアンスといった話題については，すでに十分に議論されていると思うのですが，最近になって注目されている‘DevOps’の方法論やアプローチには，どのように対応しているのでしょうか？
Bliesner: よい質問ですね。ですが，それを考える前に，DevOpsが企業にとってはまだ目新しいものであることを理解してください。 大企業で現在行われている作業の中で，DevOpsプロセスを経由しているものは10%にも達していないのです。その一方で，DevOpsで使用されているツールをいくつか調べれてみれば，それらがIT運用担当者向けに作られていないことや，企業の期待するセキュリティやコントロールのレベルに達していないことは容易に分かります。最近人気のDockerなどでも，まだまだ不十分です。数十というマイクロサービスを持ったアプリケーションを使用しているのであれば，それぞれの設定内容や，セキュリティホールの存在しないことを確認するために，さらに注意が必要になります。ハッカーにとっては，それが新たな攻撃計画の標的になるからです。セキュリティやガバナンスに関しては，決定的な方法というものが存在しないのが実情です。
InfoQ: プライベートデータセンタで稼働するビジネスプロセスのクラウド移行作業全般について，詳細な例をあげて頂けますか？開発/運用プロセスの面でどのような変更が必要なのかについての考察も，合わせてお願いします。
Bliesner: マイグレーションの方法はいくつかありますが，常に評価から始まります。最初のステップは，リホスト(re-host)やリファクタなどの手段でアプリケーションをバケツの中に入れて，リタイアさせることです。ここではそれぞれの”バケツ”が何を引き起こすのか，理解しておく必要があります。リホスト，別名“リフト・アンド・シフト”を使用すれば，アプリケーションを取り出して，最小限の変更でクラウドに移行することが可能になります。数週間で完了できる上に，アプリケーションのリファクタを予定しているのであれば，コスト的にもはるかに少なくて済みます。アプリケーションをクラウド上で実行するために変更が必要になる場合があるため，リファクタはその変更とも関係しています。いずれにしても目標は，アプリケーションないしワークロードを迅速にクラウドに移行することであり，最適化を実施できるのはその後です。
クラウド移行によるプロセスへの影響という点に関しては，オンプレミスではマルチキャストで運用されていたネットワークをユニキャストに変更する必要がある，ストレージやハイパーバイザといったインフラストラクチャの一部で視覚性が失われる，といった違いがあります。 ただし一般論として，ERPシステムのクラウドへの移行では，新しい環境でのデプロイや管理に関して，アプリケーションレベルでの大きな違いはありません。問題はマイグレーションそのものよりも，その後の管理オペレーションの方にあるのです。クラウドプロバイダは，もっと多くのメトリックを提供する必要があります。IT関係者はすべてのレイヤにおいて，詳細な情報を見ることに慣れていますから，この種のデータを欲しがります。クラウドではそれができないため，New RelicやNagiousのような監視ツールを導入して，すべてが期待通り動作していることを確認しようとする企業が増えているのです。そしてもちろん，クラウドプラットフォームのハードウェア側で発生する可能性のある問題への準備も必要です。災害復旧用のサイトとプロセスを用意しておいて，必要時にはアプリケーションを別ホストへと，迅速に移動できるようにしておかなくてはなりません。
InfoQ: 移行したアプリケーションの開発とデプロイのフェーズに関しては，一般論としてどのレベルのオートメーションが必要で，どうやって実現すればよいのでしょう？また，結果のテストとしては，どのようなものが必要なのでしょうか？
Bliesner: できる限り多くをオートメーション化した方がよいでしょう。AWSであればCloudFormationテンプレートをお勧めします。Azureにも同じようなものがあります。ERPパッケージのように大規模で扱いにくいアプリケーションを移行する場合は，オートメーションなしでは，ホットフィックスの迅速なテストが極めて困難です。データセンタ・アズ・ア・コードの考え方や変更の追跡といったものが，ベストプラクティスとしてあげられます。テンプレートを使えば，データセンタ全体を30分以内にデプロイできますし，同じ位の早さで破棄することができます。オートメーションが最も役に立つのは，時間の必要なデプロイメントを扱う場合です。バックアップサイトのワークロードの移動やテスト，作成といったものが必要な場合，テンプレートを使用すれば，後で再実行するのが非常に簡単になります。CloudFormationはテストや事前準備機能を備えていませんので，ここは試行錯誤の必要になる部分です。ですが幸運なことにそれはコードですので，私たちが行ったように，生成を自動化することが可能なのです。考え方としては，データセンタ全体をアプリケーションの観点から，必要に応じて生成と破棄が可能な単一体として扱う，ということです。これがITビジネスプロセスを変革する，クラウドの巨大な力なのです。
さらに詳しい情報は，2ndWatchのブログ記事‘top business issues when moving to the cloud’ および ‘application development in the cloud’で見ることができる。