日本のエンタープライズにおけるコンテナ活用の期待と現実 (第2回)

[TakafumiT]

新たなアイディアを生み出し、そこからいかに短期間でビジネス価値を創出できるか、という考え方が非常に重要になってきています。それは、新しいビジネス機会を獲得するために、あるいはビジネスの脅威となる競合企業に対抗するために、今求められるコンセプトです。前回の記事ではそんなお話をさせていただきました。また、そのための新しい技術の採用に関する、市場の状況について触れました。
今回はそれらを、エンタープライズITとして実際に導入するにあたってのポイントについてお話しします。

コンテナプラットフォームを構える背景
実際の導入のお話に入る前に、そもそもコンテナプラットフォームを構える背景は何でしょうか。企業により様々ですが、現時点で既に導入している、もしくは検証を始めているエンタープライズITの多くでは、企業のイノベーションをドライブする新しいアプリケーション開発をコンテナを活用して実現する、という理由がほとんどです。
具体的には下記のような背景があります。

- 今後の新規アプリケーション開発をモダンなパイプラインで回すために
- 新規で利用するアプリケーションがコンテナ化されており、それをホストするために
- モダンな開発を推進する新規開発パートナーと組むために

特に3つ目の、新しい開発パートナリングは重要なポイントの1つです。エンタープライズITとして新しいチャレンジをしていくにあたり、新しい開発パートナーが必要になります。ただ、彼らは既にモダンなプラットフォーム上で開発しています。自社ITにジョインしてもらうためには、彼らが既に活用しているようなデファクトスタンダードなプラットフォームが必要になるのです。パブリッククラウドサービスでプラットフォームを構えることもその1つですが、自社ITとしてコンテナプラットフォームを構えておくこともその重要な1つとなります。そうすることで、スタートアップ企業を含めた、新しい開発パートナリングを組む準備ができるわけです。

自社アプリケーションの適正を知る
ここまで、コンテナプラットフォームを構える背景についてお話ししましたが、エンタープライズITの既存のアプリケーションの中では、どんなものが向いているのでしょうか。もちろん、どんなアプリケーションでもコンテナ化してしまえばメリットを得られる、というわけではありません。重要なのはアプリケーションと、それらが提供するサービスの特性です。それらを把握し、適切なプラットフォームにデプロイしなければ、無駄が多く発生してしまいます。実際、そういったミスマッチが起きている現場は少なくありません。
それら特性の判断基準にはいろいろな要素がありますが、アプリケーションの更新頻度はその重要なポイントの1つです。1度デプロイしてそのままずっと起動し続ける、ほぼ更新がかからない、そういった特性を持つアプリケーション（つまり、1度リリースしたら「塩漬け」しておきたいもの）などは、これまでどおりの物理環境、あるいは仮想環境でしっかり守るべきです。そうではない下記のようなアプリケーションは、これまでのプラットフォームで稼働させていては、スピードが間に合わず、その遅れはビジネス損失に直結します。

- 機能追加が短期間で何度も必要

- 頻繁なバージョンアップを繰り返すSNSなどの外部サービスと連携していて、それに追随する必要がある

上記のような、各アプリケーションとそれらが提供するサービス、ならびに連携する先のサービス群、それらの特性を改めて把握し、そのそれぞれの特性に合ったプラットフォームを準備することで、都度適切に選択できるようすることで、期待するメリットを早く享受することができます。

変化に強くなる
実際の導入では、非常に多くの変更が発生し続けます。そのため何事も変化に強くなること、つまり、変更要求に対する対応スピードが求められます。具体的には、下記のような要求に迅速に対応する必要があります。
- 必要に応じたインフラリソースのスケールアウト、スケールイン
- アプリケーションコード変更などの更新から、新バージョンのリリース
- 新しいサービス追加

特に新サービス追加時は、ネットワーク設定変更など、多くの要因で時間がかかりがちです。もしかしたら、Global IPアドレスの取得、Reverse Proxyの設定追加、ファイアウォールの追加穴空け、SSL証明書発行、などなどの作業を、組織を跨いだ申請や人手によるオペレーションであったり、隔週・月次などのタイミングでしか実行されないバッチ的なオペレーションであったりでしか実行できないかもしれません。継続的デリバリーを実現できていても、このような要因で時間がかかると、結局、計画からリリースまでのライフサイクル全体の迅速性が阻害されます。ただ、たとえばこれはサービスデザインで回避することができます。ここでは詳細まで触れられませんが、サービスデザインするにあたり、インフラ側の視点ではなく、アプリケーション側のサービスの視点に立ち、リリースまでのライフサイクル全体のスピードを阻害する要因、フェーズ、を特定し、それを避ける、ということを常に意識しながらデザインを進める必要があります。

また、変化に強い必要があるのはプラットフォームだけではありません。それらを実装していくにあたってのプロジェクト推進も同じです。最初に要件をすべてFIXしてから、それを設計・構築する、という進め方では、プロジェクトが破たんするか、あるいは最終的に期待したプラットフォームは完成しません。単純にインフラを構築するというプロジェクトと異なり、ほぼすべてのフェーズにおいてアプリケーションの要件（変更要求）を考慮する必要があるためです。こういったプラットフォームで開発するアプリケーションは、高頻度で設計変更が発生します。ただ、すべての変更を受けれていたら、それは全体の迅速性を阻害します。プロジェクトの中では、各要件や設計における、その変更のインパクト（各要件や設計の依存関係）を常に把握し続けつつ、限りなく変更を受け入れる必要があります。

つまり、アプリケーションの変更要求を柔軟に汲み取れる変化に強いプロジェクトを、変化に強いプラットフォームが支えるということです。これは当然、リリース後の柔軟性にもつながります。

- 小さく1stリリースする
- 継続的に変更とリリースを繰り返す
- 都度効果を判断し、必要に応じて素早くスケールする
- 効果を判断する

これを繰り返していくことでプラットフォームが成長し続けます。結果、そこから提供するサービスの質が上がり続けます。プラットフォームもプロジェクトも、変化に強くなる必要がある、というのはこういうことなのです。

実際の導入にあたっての背景と、その際に押さえておかなければならないポイントについてお話ししました。この後、技術、ソリューション、ツールの選定をする必要がありますが、このためには、アプリケーション開発要件とプラットフォーム運用を意識する必要があります。たとえば、アプリケーション開発要件としては、デファクトスタンダード、つまりCommunityが活発なソリューションに対する要求が高まります。同時にそれらは、進化のスピードが非常に早いため、プラットフォーム運用に高いCapabilityが求められます。次回以降では、具体的な事例案件などをベースに、より詳細なお話ができればと思っています。