The Doppler Quarterly (日本語) 春 2016

なっています。したがって、アプリケーションをリファクタリングし、コンテナーの単なる集まりとしてだけでなく、コンテナーのクラスターとしてスケールできるようにするには、どれだけの作業が必要かという問題があります。コンテナーの使用に関する分析には、実際にアプリケーションを 1 つのコンテナーに変換するか、またより一般的な状況として複数のコンテナーのセットに変換するために、どれくらいの労力を要するかを判断することが含まれます。コンテナーへの変換が実用的ではない場合もありますが、通常は、比較的簡単に行うことができます。アプリケーションをクラウドプラットフォームに移植する際の分析段階でも同じような問題に取り組んでいるため、 TCO に関する同じメトリックやモデルの多くは、この問題にも当てはめることができ、再利用できます。 3. スタッフのスキルを考慮しますほとんどの企業では、クラウドに移行しているワークロードの数は多くはありません。移行先がクラウド上で実行されているコンテナーの場合はなおさらです。多くの点で、この制限の原因はテクノロジーではなく、 IT スタッフのスキルセットにあります。企業がコンテナーへの移行を行う際は、コンテナー化されたアプリケーションを構築して展開するためのスキルセットを習得するために、トレーニングと雇用に多額の投資をする必要があります。この状況をさらに複雑にする要因として、多くの企業はアプリケーション開発のアジャイル手法を自動化する手段として DevOps を導入しつつあり、そのためにコンテナーの導入を検討する必要に迫られています。そのような企業では、 IT 組織が最初にコンテナーの導入を決定し、その後に DevOps の変革を進めることになります。このプロセスによってリスクが減り、コストも削減されます。 4. 戦略を再検討します企業は、クラウドコンピューティングの戦略を策定して実施したように、今度はコンテナーをサブ戦略として検討する必要があります。実際に、コンテナーはクラウド戦略全体の構成要素として、置き換えや引き継ぎが起こることのない実現技術となります。最終的には、コンテナー内のアプリケーションを展開しますが、これに新しい要素はありません。インターネットが登場した際に見られた導入のパターンと、アプリケーションサーバーのリスクは、テクノロジーが新しいことを除けばほぼ同じです。コンテナーを革新的なテクノロジーだと考えると、失望することになります。良くても発展と言えるレベルですが、それでも、クラウドベースアプリケーションに適した、よりスケーラブルでポータブルなプラットフォームを提供します。コンテナーは、 IoT アプリケーション、ビッグデータ、さらにはオンプレミスにとどまる従来型のオンプレミスシステムと組み合わせて使用することもできるため、クラウド専用とは言えませんが、主としてクラウド向けのテクノロジーだと言えるでしょう。 5. 徹底的にテストしますコンテナーに移行する企業は、テストプラットフォームを作成して、このテクノロジーの実際の限界を把握する必要があります。この限界の主な項目は次のようなものです。 • データ。従来型のインターフェイスを使用してデータを活用する場合と比べて、データをコンテナー化する際の制限は何ですか。 • 管理。コンテナーのクラスターを長期間にわたってどのように管理しますか。 • ガバナンスとセキュリティ。どのような方法でコンテナーを制御してセキュリティで保護し、その結果、拡張性、パフォーマンス、安定性にどのように影響しますか。コンテナーの普及コンテナーの利用はさまざまな企業で急速に成長しており、この分野のベンダーは、必要な資金をすべて投じて企業やクラウドプロバイダーから求められる改善に取り組んでいます。とはいえ、コンテナーはあらゆる問題を解決するわけではありません。企業がこのテクノロジーへ移行する際は、注意深く進んでいく必要があります。この分野が成長を続け、導入のペースが鈍ることがなければ、コンテナーのユーザーはこのテクノロジーについてさらに多くの事柄を学んでいきます。その途中で得られる驚きには嬉しいものもあれば、そうでないものもあるでしょう。いずれにせよ、このテクノロジーの限界についての理解を深め、ビジネスに役立てるための最適な活用法を把握することができる点は喜ばしいことです。 • 拡張性。どのようなタイプのワークロードをスケールすることができ、どのような方法でスケールできますか。 • 安定性。コンテナーを不安定にするのは、どのような動作や負荷ですか。 2016 年春号 | THE DOPPLER | 15

The Doppler Quarterly (日本語) 春 2016 | Page 17