モノリスをマイクロサービスに移行する
モノリスを取って容器に入れれば、出来上がり! という空想的な信念があります。 規模とスピードの現代建築の利点。
実際、 KubeKon 2018 の調査では、コンテナを「既存のアプリの VM の代替として」活用していると回答した回答者の約 55% がまさにその状況に陥っていることが示唆されています。 他の調査では、かなりの量のエンタープライズ クラスの Java アプリケーションがコンテナ内で実行されていることが示されています。 2018 年の Diamanti の調査によると、大多数 (54%) がクラウド ネイティブ アプリにコンテナーを使用していましたが、ほぼ 3 分の 1 (31%) がレガシー アプリケーションの最新化にコンテナーを使用していました。
挙げられる理由は一般的に運用上のもので、管理しなければならない可動部品が急増しているにもかかわらず、コンテナの方が管理が簡単だと考えられています。 パフォーマンスとライセンス料金も、コンテナの導入を決定する際の要因となることがよくあります。
しかし、その移行は、レガシー アプリをラップしてコンテナーにドロップするほど簡単ではありません。
現実には、モノリス (従来のクライアント サーバーおよび Web アプリ) には、コンテナーにリフト アンド シフトして運用上のメリットを享受することが難しい特定の特性があります。 コンテナとマイクロサービスは相互に包含的ではありませんが、どちらも最新のアプリの可用性の基盤となる「障害を想定して構築」の原則に傾いています。 その原理は、もしご存知ない方のために説明すると、1 つのコンテナに障害が発生した場合、その代わりに別のコンテナを起動するだけです。 すべてのコンテナは牛であり、どれも同じくらい優れています。
意図的に最新のステートレス アプリケーション アーキテクチャでは、これは当てはまります。 従来のステートフル アプリケーション アーキテクチャでは、それほどではありません。
ご存知のとおり、クライアント サーバーとその後継である 3 層 Web アプリは、一般的にステートフルです。 セッション中のクライアントとアプリ間のやり取りに関する特定の情報を保持します。 そのセッションは、アプリまたは Web サーバー上のメモリ、または別のデータベースに保持される可能性があります。 データがどこに保存されているかに関係なく、それがアプリをステートフルにするものです。 このデータはアプリの運用に関連し、重要です。このデータには、ショッピング カート、最後にアクセスしたページ、その他のアプリ固有の情報が含まれます。
その情報が保存されている Web サーバーまたはアプリ サーバーが突然消えてしまった場合、クライアント エクスペリエンスに悪影響が出ることは想像に難くありません。 カートが消えてしまいました。 元いた場所まで戻らなければなりません。 基本的に最初からやり直さなければなりません。
この動作は、アプリケーションのステートフルな操作を排除する最新のアーキテクチャ原則とは正反対です。 何か問題が発生した場合に、あるインスタンスを別のインスタンスにシームレスに置き換えることができるのは、最新のアプリやサービスのステートレスな性質によるものです。 それは、「失敗を前提に構築」が機能するための基盤です。 その方程式に状態を再び導入すると、突然すべてが崩壊します。
アプリは引き続き動作しますが、ユーザーは宙ぶらりんの状態になります。 彼らの流れは中断され、彼らの取引は冥界へと運ばれ、二度と見られなくなります。
この問題は、アプリケーション サービスが状態を尊重する必要性を生じさせた問題です。 クライアントが特定のアプリ/Web サーバーに接続すると、セッションの存続期間中は同じアプリ/Web サーバーに接続する必要がありました。 リクエストが常に同じサーバーにルーティングされるようにするために、Cookie の永続性やその他のメカニズムが開発されました。 状態を維持するため。
現実には、グリーンフィールドのスタートアップでない限り、現在は従来のアプリケーションと最新のアプリケーションの両方が稼働しています。 このテーマに関する調査はさまざまですが、「63% のレガシー アプリと 37% の新しいアプリ」という割合は、時間の経過とともにほぼ一貫しています。 つまり、レガシーアーキテクチャと最新アーキテクチャの両方を同時にサポートする必要があるということです。
ステートフルとステートレスの間の境界に対処していなければ、モノリスをコンテナに移動するだけでは役に立ちません。
建築階層化
モノリスからコンテナ化された環境への移行を管理する最善の、または少なくとも最も簡単な方法は、コンテナ クラスターのステートレスな無秩序状態においても状態を尊重できるようにすることです。 これには、クラスターの端、つまり南北と東西が交わる入口でのスマートさが必要です。
2 層アプローチは、従来の運用アプローチと最新の運用アプローチの両方をサポートするほか、従来のステートフル アプリをコンテナー化された環境に移行することもできます。 F5 Container Ingress Services (CIS) を活用することで、NetOps はコンテナ化された環境に移行するステートフル アプリケーションのニーズを継続的にサポートできます。 この接続により、永続性を採用した従来の負荷分散方法が引き続き動作し、リクエストを適切なコンテナまたは従来の環境に直接送信できるようになります。
一方、BIG-IP は、最新のアプリや API に対するリクエストをコンテナ クラスタ内のイングレス コントローラに同時に送信し、必要な数のステートレス コンテナに分散させることができます。
移行には時間がかかる
現実には、ほとんどの組織は、モノリスからモバイル、マイクロサービスまで、最大 5 つの異なるアプリケーション アーキテクチャをサポートしています。 同数ではあるものの異なる数のネットワーク モデルと運用モデルを同時にサポートすると、運用に負担がかかり、最新のアーキテクチャと環境に移行するメリットが失われてしまいます。 戦略的な 2 層アプローチにより、組織は大部分がコンテナ化された環境に移行しながら、両方のモデルの運用上およびビジネス上のメリットを最大限に引き出すことができます。
リファクタオプション
この移行を容易にするためにできることの 1 つは、共有セッションを活用するようにレガシー アプリをリファクタリングすることです。 これらのセッションは、Web/アプリケーション サーバーとは別の場所 (通常は何らかのデータベース) に保持され、適切なセッション ID を持つ任意の Web/アプリケーション サーバーからアクセスできます。 セッション ID を追跡する必要はありますが、これは通常、Web/アプリ サーバーの状態に関係なく保持される Cookie を介して実現できます。 レガシー アプリがまだ共有セッション モデルを使用していない場合、共有セッション モデルを使用するようにリファクタリングすることは、アプリ全体を再プラットフォーム化するのに比べて、かなり簡単なプロセスです。
このような移行には時間がかかるため (結局のところ、現在でもほぼすべてがマルチクラウド モデルで運用されています)、可用性やセキュリティなどのコアな顧客ニーズを損なうことなくメリットを最大化するアーキテクチャ オプションを見つけて活用することが重要です。 2 層アーキテクチャ アプローチを使用すると、コンテナ化の取り組みを制限することなく、両方を実現できます。