【Vol.01】アプリケーションをコンテナ化！
検討すべきポイントとは？

少数のコンテナに集約できるようなアプリケーションで完結する、つまり単純なシステムの場合は、Kubernetesではなく、Docker/Docker Compose環境でも問題ないかもしれません。一方、多数のコンテナを必要とするサービスやマルチテナントを実現したい、スケールアウト/スケールインを頻繁に行いたい場合などは、Kubernetes環境が向いています。今回検証対象としたAI Digは、顧客を増やしていくためにマルチテナント化したい、という課題があったことから、Kubernetes環境 / OpenShift環境でのコンテナ化を目指しました。

Docker/Docker Compose環境、Kubernetes環境、OpenShift環境、いずれの環境の場合でも、コンテナ化するにあたって検討すべきポイントは変わりません。今回は、コンテナ化する際の検討フェーズ〜コンテナイメージの方針確定までをご紹介します！

AI Digは、AIを活用したコンタクトセンター向け応対支援サービスです。複数の言語で開発されたアプリケーションとミドルウェア、AIサービスから構成されるソリ ューションで、お客さまごとにIBM Cloudの仮想サーバー上に独立したシステムを展開しています。主要な機能としては、ユーザインタフェース、ログイン認証、会話ログの保存、Watson連携、リソース管理などのモジュールからなり、アプリケーションは状態を持たないステートレスな構成です。

ミドルウェア： Nginx/PostgreSQL/CouchDB
アプリケーションで使う言語：Node.js/Java+Spring Frameworkなど
AIサービス：Watson Assistant、Watson Discovery、Watson Speech to Text

・ 顧客ごとにインフラ環境(IaaS)の構築が必要なため、インフラ費用、構築コスト、管理コストが大きく、サービス開始にも時間がかかる
・ リリース手順が複雑であり、属人化やデプロイ作業に時間が掛かる状況にある
・ 顧客数を増やしていくにあたり、マルチテナント化を行える環境を整備したい
・ サービスの可用性やメンテナンス性を向上したい
・ アプリケーションの開発・リリースサイクルを向上させたい

コンテナ化の際に検討すべきポイント、まず1つ目は「アプリ分析」です。

アプリケーションの特性によっては、コンテナ化の「向き不向き」があるため、コンテナ化が可能なのか、メリットを享受できるのかを3つのポイントで見極める必要があります。

(1) マイクロサービス化できる？
コンテナ化する際、1つのコンテナに対して1つのアプリケーション（プロセス）が実行されることが最も効果的に機能すると言われています。そのため、モノリシックアプリケーションをそのままコンテナ化することは好ましくなく、機能ごとに分離されたマイクロサービスアプリケーションがコンテナに向いています。「Beyond the 12 Factor App」へ準拠が可能かも判断の1つと言えるでしょう。

(2)リリース頻度は高い？
コンテナ化するメリットの1つに、アプリケーション開発の効率化・高速化があります。そのため、あまり頻繁に開発が行われないシステムに対して、コンテナ化をしてもあまりメリットはないかもしれません。

(3) システム要件を満たしている？
サードパーティー製のソフトウェアや特定のライブラリに依存する場合は注意が必要です。ライセンスや動作要件上、コンテナでの動作が許可されないものや保証されないケースがあります。

２つ目のポイントは、稼働環境の選定です。プライベートクラウド、オンプレミス など、どの環境で稼働させるか、利用用途やコンテナ化するアプリケーションの特性に応じて決める必要があります。

IBM CloudやAWS、Microsoft Azureなどのクラウドベンダーから提供されている「マネージドサービス」は、すぐに利用開始できる他、インフラ構築・運用をクラウドベンダーにお任せできるため、アプリケーション開発・運用に集中することができるというメリットがあります。

一方で、より自由にKubernetes環境を利用したい場合には、クラウド上の仮想OSやベアメタルサーバーを用いて、自身でKubernetes環境を構築することも可能です。また、インターネットに接続させたくない、専有環境で使用したい場合などは、オンプレミスで構築するのもオススメです。

その他、外部サービスとの連携やコストなどにより、どの環境でコンテナアプリケーションを動かすか判断する必要があります。

最後に、監視、バックアップなどの非機能要件をどこまで実現するかを整理する必要があります。コンテナ化する場合、従来通りの方法では非機能要件をうまく実現できない可能性があります。第2回目のコラムで詳しく紹介しますが、ログ管理などは、従来とは違う、各環境ごとの独自の考え方・実現方法で構築する必要ががあります。ここでは、実現したい非機能要件を整理し、次のステップで実現方法を定義していきます。


以上の3つの観点で、AI DIgを分析し、どのようにコンテナ化するか、以下のように方針をまとめました。

AI Digのコンテナ化の方針が固まったところで、次に、ミドルウェア、アプリケーションごとに分離・コンテナ化を実施します。

【設計時に考慮したポイント】
・ 環境変数や設定ファイルの配置場所（コンテナイメージ内 or 外）
・ 利用イメージの選定（公式イメージ or カスタムイメージ）
・ アプリケーション分離 (どの単位で分離させるか）

汎用的な設定/機能なのか、お客さま独自の設定なのかにより、どこまでコンテナイメージに含めるのかを検討する必要があります。マルチテナント化や今後サービスの改修/アップデートの可能性もあること、マイクロサービスを意識し、変更の可能性のあるパラメーターを特定し、コンテイメージに含めないようにするとともに、ハードコードされた設定値などを外部に持たせるように設計します。

Immutable Infrastructureを実現するイメージにすることも重要です。コンテナイメージを起動するたびに外部要因（パッケージ取得先の障害やバージョンが変わったなど）により、実行結果が毎回変わってしまうことは好ましくありません。実行バイナリや関連パッケージは可能な限りコンテナイメージの中に含める必要があります。

このように、コンテナイメージに何を含めて、何を含めないかを判断していく必要があります。何でもかんでもコンテナイメージに含めてしまうと、うまく行きません。汎用的な要素はコンテナイメージの「外」で管理するようにし、お客様ごとに変わる設定はコンテナイメージの「中」で管理するようにしましょう。

今回は、作成したコンテナイメージをIBM Cloudが提供するContainer Registryサービスに保管しました。IBM Cloudアカウントでのアクセス制御が可能で、安心してプライベートイメージを保管することができます。また、コンテナイメージの脆弱性スキャンが標準装備されており、安全なコンテナイメージをKubernetes(IKS)環境にデプロイすることができるのもポイントです。

コンテナ化までが終わったので、第2回では、Kubernetes（IKS）環境の設計・設定とアプリケーションのデプロイまでを検証していきます！