コンテナ適用による変化
クラウドネイティブNow

新規構築でコンテナ適用する場合

新規構築でコンテナを適用する場合、ビジネスアジリティの高いシステムにするために、次のようなアーキテクチャーや手法の採用を検討する必要があります。

マイクロサービスアーキテクチャーの採用や、CI／CDの導入を行う

マイクロサービスアーキテクチャーの採用、CI／CDの導入を検討してください。これにより、コンテナ適用のメリットに加え、サービスリリースの高速化やリリースによる影響の局所化を実現し、俊敏なシステム改善を行うことができるようになります。

コンテナオーケストレーションの機能を活かすシステム構造とする

コンテナを適用しシステムを運用する際に重要なコンテナオーケストレーションの機能を活かせるよう、ステートレスなアプリケーションにすることを検討してください。これにより、自動復旧やオートスケールといった機能を活かしやすく、柔軟性や回復性を高めることができます。

基盤機能を独立させ、各コンテナから利用する方式とする

認証・認可やログ収集、監視機能などの基盤機能を、業務機能から独立させる構造にすることを検討してください。これにより、基盤機能の改修や入れ替え・追加などを柔軟に行うことができるようになります。これらの基盤機能に該当するサービスは、各クラウドサービスが提供しているものもあるので、適用可否も併せて調査・選定することを推奨します。

既存システムをコンテナ移行する場合

コンテナ化に向いているかどうかや、メリットの大きさを調査し、コンテナ化するかどうかを検討する必要があります。検討する際のポイントには次のような点があります。

システム構成

一般的に移行に向いているものとしてウェブアプリケーションが挙げられます。これは、ウェブアプリケーションに使用されているソフトウェアなどがコンテナに対応しているものが多く、また、システムの特性上GUI部の処理などを利用者側の機器に任せる場合が多いからです。

リリース頻度

コンテナ化の大きなメリットの一つとして、さまざまな環境下への移動が容易であり、リリース作業の効率化や起動時間を短縮できるというものがあります。このメリットを十分に活かしたい場合は、対象となるシステムが今後もエンハンスを継続して行うものであることが望ましいです。逆に、すでに開発計画が終息しており、エンハンスも行わないようなシステムではメリットを活かしづらく、移行コストやランニングコストのみが膨らむ可能性もあります。

製品ライセンスや動作保証

システムで使用している製品やオープン・ソース・ソフトウェア（OSS）のライセンスがコンテナ上での使用に対応していることを確認する必要があります。対応してる場合であっても、ライセンス数の考え方や、移行後のシステム構成によっては想定外のライセンス料が発生する恐れもあるので注意が必要です。また、現在使用しているライセンスが対応していない場合であっても、最新バージョンであったり、他のライセンス形態であれば対応していることがありますので確認してください。

1. 1st STEP

   既存システムのコンテナ化

   最初のステップとしてモノリシックな構造のまま単純移行を行い、その後、段階的にさまざまな技術を適用していくスモールスタートのアプローチをとることもできます。これにより、インフラサービスの型化や提供までの期限（コンテナ自体は数秒から数十秒で配備可能）が短縮されます。また、1st STEPから必ず行わなければいけないという訳ではなく、2nd STEPからスタートするといった進め方でも問題ありません。ただし、コンテナ基盤やオーケストレーションツールのサポート期間がシビアという問題もあるため、1st STEPのみの対応は推奨しません。

2. 2nd STEP

   既存資産とのハイブリッド

   既存資産はそのまま運用しつつ、新機能をAPIなどで既存の仕組みに結合します。新機能を既存資産の仕組みにとらわれず、新規リリースの高速化や、新機能の実現手段として、適材適所でクラウドサービスなどを選択し、サービス連携を実現します。テストの一部を自動化することで、テストの期間短縮や工数削減が実現できます。また、俗人化の排除により品質向上も期待できます。

3. 3rd STEP

   アーキテクチャー移行

   既存資産を、マイクロサービスやCI／CDなどのクラウドネイティブ技術を適用して移行します。これにより、業務リリース全体の高速化と、既存資産（アプリケーション）を意識せずにさまざまなプラットフォームやアーキテクチャーが選択できるようになります。また、業務開発プロセスにあたっては、必要最低限を除くテストの自動化による高速化・省力化、さまざまなデリバリースタイルの実現により安全なリリースが実現できます。

これにより、まずは自動化や標準化による効率化を行い、最終的に変化に強く新たな価値を生み出すITへと進化させて行くことができます。「このシステムで適用は無理だ」という先入観を持たずに、適用できる領域がないか？をまずは検討してください。

アプリケーション開発における変化

アプリケーション開発における変化は次のような点があります。

データが揮発性であるため、それに対応するアプリケーション構造とする必要がある

コンテナの特性として、データが揮発性であるという点があります。そのため、ファイル出力を行う場合、コンテナ内ではなく外部に保存・連携する方式の採用が必要です。例としては、ホストOSに割り当てたディレクトリー・外部ストレージへの保存や、コンテナ外にログ収集の仕組みを導入するといったものです。

環境ごとの設定値を外部から設定する方式を検討する必要がある

コンテナの利点を活かすために、作り直し不要な可搬性の高い構造とすることが推奨されます。そのため、環境ごとに変更しなければいけないデータベースの設定などについては、コンテナ内部に持つのではなく、環境変数で実行時に設定できる仕組みを導入するといった方式を検討する必要があります。

ステートレスな方式や、機能を細分化した設計を検討する必要がある

コンテナオーケストレーションの機能を活かすために、ステートレスな方式とすることが推奨されます。これにより、自動復旧やオートスケールが発生してもシステム全体としては正常に稼働している状態を継続できます。また、機能を細分化することにより、機能ごとでのオートスケールの実施や、障害発生時の影響を特定機能に抑えることもできます。

インフラ構築における変化

インフラ構築における変化は次のような点があります。

手順書＋コマンドでの構築から、設定ファイルによる構築に変わる

従来、環境構築時は手順書や設計書を基にしてその都度コマンドを実行していました。それに対し、コンテナでの環境構築はあらかじめ設計情報などを構成ファイルに記載し、それを実行する形です。これにより、構築の自動化や、設計情報の構成管理が容易です。

環境のチューニングや設定変更は、その都度新規に環境を作る

従来、環境のチューニングや設定変更を行う場合、作成済環境に対して追加・変更を行っていました。それに対し、コンテナでは既存環境は破棄し、チューニングや設定変更を反映したコンテナをその都度新規に作成・配置する「イミュータブルインフラストラクチャー（Immutable Infrastructure）」と呼ばれる形態です。これにより、環境がクリーンな状態を保ち、意図しない環境変更が起きにくくなります。

運用における変化

運用における変化は次のような点があります。

コンテナオーケストレーションの機能での自動化に対応する必要がある

仮想マシン（VM）の機能で行っていた部分がコンテナオーケストレーションの機能に置き換わったり、組み合わせて運用することで、自動復旧やオートスケーリングなど、より回復性の高いシステム運用ができます。また、WebAPIなどを活用して更なる自動化を進めることで、今まで以上の負荷軽減を行うこともできます。Kubernetes（クバネティス）では、Operatorという機能を使って拡張することで障害発生時の対応なども自動化が可能です。

サービス全体を監視する、統合型システム監視が必要となる

個々のコンテナの稼働状況の監視や、不調時の自動復旧などについては、コンテナオーケストレーションの機能を使用して行うことができるため、運用者の作業を大幅に効率化できます。それとは別に、運用者は、コンテナ単体に対してではなく、サービス全体が安定して利用可能な状態になっているかという観点で、統合型のシステム監視を行う必要があります。

コンテナの世代管理が必要となる

従来行ってきた仮想マシンのスナップショットやバックアップに加え、コンテナ自体の世代管理も行う必要があります。管理するものは増えますが、コンテナの世代管理を行うことにより、問題発生時のロールバックなどを容易にかつ素早く実現できるようになります。

関連情報

• FUJITSU Hybrid IT Service FJcloud-O
• Red Hat OpenShift Container Platform