モノリスをマイクロサービスへ移行

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

モノリスをコンテナに入れるだけで、あっという間にスケーラビリティとスピードというモダンアーキテクチャのメリットが得られる、という夢物語があります。

実際、KubeKon 2018の調査によると、コンテナを「既存アプリケーションのVM代替」として活用していると回答した約55%が、まさにそのような使い方をしていることが示唆されています。ほかの調査では、相当数のエンタープライズクラスのJavaアプリケーションがコンテナで稼働していることが示されています。2018年のDiamantiの調査では、過半数（54%）がクラウドネイティブアプリケーションにコンテナを使用していた一方、3分の1近く（31%）がレガシーアプリケーションのモダナイゼーションに使用していたことが示されています。

一般に挙げられる理由は運用面に関するものです。管理すべき構成要素が急増するにもかかわらず、コンテナの方が管理しやすいと考えられています。また、コンテナの導入を決定する際には、パフォーマンスやライセンス料も判断材料となることが少なくありません。

しかし、その移行は、レガシーアプリをパッケージ化してコンテナに入れるだけで済むほど単純ではありません。

実際のところ、従来型のクライアントサーバーアプリやWebアプリなどのモノリスには、コンテナへのリフト＆シフトや、その運用上のメリットの享受を難しくする特性があります。コンテナとマイクロサービスは必ずしも一体ではありませんが、どちらもモダンアプリの可用性を支える「障害を前提とした設計」の原則に基づいています。この原則は、あるコンテナに障害が発生した場合、代わりとなる別のコンテナを起動すればよい、という考え方です。すべてのコンテナは個体を区別しない「家畜」として扱われ、どれも同等です。

意図的にモダンなステートレスアプリケーションアーキテクチャとして設計されている場合は、そのとおりです。一方、従来のステートフルアプリケーションアーキテクチャには、あまり当てはまりません。

クライアントサーバー型アプリケーションと、その後継である3層Webアプリケーションは、一般にステートフルです。クライアントとアプリケーション間のやり取りに関する特定の情報を、セッション内に保持します。このセッションは、アプリケーションサーバーやWebサーバーのメモリ内、または別のデータベースに保存される場合があります。保存場所にかかわらず、このデータがあることでアプリケーションはステートフルになります。このデータはアプリケーションの動作に関係し、重要な役割を果たします。ショッピングカートの内容、最後に閲覧したページ、その他のアプリケーション固有の情報などが含まれます。

その情報を保持しているWeb／アプリサーバーが突然停止すると、クライアント体験が損なわれることは容易に想像できます。カートの中身が消え、元の場所まで戻って、最初からやり直さなければなりません。

この動作は、アプリケーションのステートフルな運用を排除する現代のアーキテクチャ原則とは真っ向から対立します。現代のアプリやサービスはステートレスであるため、問題が発生しても、あるインスタンスを別のインスタンスにシームレスに置き換えられます。これが「障害を前提とした設計」を成り立たせる基盤です。そこに再び状態を持ち込むと、すべてが一気に破綻します。

アプリは引き続き動作するものの、ユーザーは宙ぶらりんの状態に置かれます。処理フローは中断され、トランザクションは行方不明となり、二度と復元できません。

この問題をきっかけに、アプリケーションサービスには状態を考慮することが求められるようになりました。クライアントが特定のアプリケーション／Webサーバーに接続すると、セッションが継続している間は同じサーバーに接続し続ける必要があります。リクエストが毎回同じサーバーにルーティングされるよう、Cookieパーシステンスなどの仕組みが開発されました。状態を維持するためです。

実際のところ、ゼロから事業を立ち上げたスタートアップでない限り、従来型とモダンの両方のアプリケーションが現在稼働しています。この点に関する調査結果にはばらつきがあるものの、「レガシーアプリ63%、新規アプリ37%」という比率は、長期にわたりおおむね変わっていません。つまり、レガシーアーキテクチャとモダンアーキテクチャの両方を同時にサポートする必要があります。

ステートフルとステートレスの違いに対処しないまま、モノリスを単にコンテナへ移行しても、問題の解決にはつながりません。

アーキテクチャの階層化

モノリスからコンテナ化環境への移行を管理するうえで最善の方法、少なくとも最も容易な方法は、コンテナクラスターというステートレスで無秩序な環境でも、ステートを適切に扱えるようにすることです。そのためには、N-SトラフィックとE-Wトラフィックが交わるイングレス、つまりクラスターのエッジにインテリジェンスが必要です。

2層型のアプローチは、従来型とモダンの両方の運用アプローチに加え、従来型のステートフルアプリケーションからコンテナ化環境への移行もサポートします。F5 Container Ingress Services (CIS)を活用することで、NetOpsは、コンテナ化環境へ移行するステートフルアプリケーションのニーズを引き続きサポートできます。この接続性により、パーシステンスを使用する従来の負荷分散方式を継続して運用し、適切なコンテナまたは従来型環境に直接リクエストを振り分けることができます。

一方、BIG-IPは、モダンアプリやAPIへのリクエストをコンテナクラスター内のIngress Controllerに同時に転送し、必要な数のステートレスコンテナに分散できます。

移行には時間がかかる

実際のところ、ほとんどの組織では、モノリシックアーキテクチャからモバイル、マイクロサービスまで、最大5種類もの大きく異なるアプリケーションアーキテクチャをサポートしています。同時に、同数の異なるネットワークモデルと運用モデルをサポートすれば、運用チームに過大な負担がかかり、最新のアーキテクチャや環境へ移行するメリットが損なわれることは避けられません。戦略的な2層アプローチを採用することで、コンテナ化された環境が大半を占める状態へ移行しながら、両方のモデルから運用面とビジネス面のメリットを引き出せます。

リファクタリングの選択肢

この移行を容易にする方法の1つは、レガシーアプリをリファクタリングし、共有セッションを活用できるようにすることです。共有セッションはWeb／アプリサーバーとは別の場所（通常は何らかのデータベース）に保持され、適切なセッションIDがあれば、どのWeb／アプリサーバーからでもアクセスできます。セッションIDの追跡は引き続き必要ですが、通常はWeb／アプリサーバーの状態にかかわらず保持されるCookieを使用して対応できます。レガシーアプリが共有セッションモデルをまだ使用していない場合でも、アプリ全体をリプラットフォームする場合と比べれば、共有セッションモデルを採用するためのリファクタリングは比較的容易です。

このような移行には時間がかかります。実際、現在もほぼすべての組織がマルチクラウドモデルで運用しています。そのため、可用性やセキュリティといったお客さまの中核的なニーズを損なうことなく、メリットを最大化できるアーキテクチャ上の選択肢を見つけ、活用することが重要です。2層アーキテクチャのアプローチを採用すれば、コンテナ化の取り組みを制約することなく、可用性とセキュリティの両方を確保できます。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事