その巨大なモノリシック アプリケーションをコンテナーに詰め込むにはどうすればよいでしょうか。

皆さん、こんにちは。 「巨大なモノリシック アプリケーションをコンテナーに詰め込む方法」へようこそ。 私の名前はケビン・バーフィールドです。 私はDockerのプリンシパル・ソリューション・アーキテクトです。 この役職に就く前は、Java開発者、Javaアーキテクト、そしてJavaミドルウェアの販売をしていました。 ですから、このプレゼンテーションにはJavaが使われていることが想像できるでしょう。

さて、議題について話しましょう。 コンテナの理想とモノリシックなアプリケーションの現実について説明します。 このセクションでは、新しい責任を与えられた新しいエンタープライズ アーキテクトとしての役割に身を置き、そこで一種の厄介な驚きを与えます。 次に、モノリシックなアプリケーションのモダナイゼーションとコンテナに飛び込みます。 そこで、アプリケーションをモダナイズするためのさまざまな戦略と、コンテナがそれにどのように役立つかについて説明します。 前もって明確にしておくと、これはアーキテクチャ レベルになります。 コードやDockerファイルなど、そのようなものを分割するつもりはありません。 私は、物事にアプローチするための戦略と方法について話すつもりです。

コンテナの理想とモノリスの現実

さて、コンテナの理想とモノリスの現実。 私が会社の新しいエンタープライズアーキテクトであるとします。 新しいプロジェクトが始まると言われて、それをどうするかのアイデアが浮かびました。 コンテナを使った開発をしてきた者として、私はコンテナを信じ、コンテナ化の利点を信じており、それを広く広めたいと思っています。

コンテナ化の利点は何ですか? 1 つ目は、コンテナーがプロセス レベルの分離を提供することです。 CPUの量を分離できます。 ストレージの量を制限できます。 ネットワークを制限できます。 この特定のコンテナーで使用されるメモリを制限できます。 これは、同じハードウェアにより多くのリソースを詰め込むことができることを意味し、これは素晴らしいことです。 また、アプリケーションが必要とするすべての依存関係をコンテナーにまとめることもできます。 ですから、私のマシンで動くようになったと開発者に言わせることはもうありません。

コンテナにより、アプリケーションの配布と移動が容易になります。 コンテナを拾うことができます。 別のマシンで実行しても、同じように実行されます。 そのため、これらのものを簡単に移動できるという安心感を得ることができます。 コンテナはOCI標準を使用します。 つまり、Dockerを使用してコンテナを構築したか、Rancherまたは他の誰かの製品を使用して実行したかは関係ありません。 OCI標準に適用できれば、すべての主要なDevOpsツールベンダー、すべてのクラウドプロバイダーがそれをサポートすることになります。 そして最後に、私の意見では、最も重要なことですが、アーキテクトとして、開発者はコンテナを使用してアプリケーションを構築する方が優れたエクスペリエンスを得ることができます。

コンテナのベストプラクティス

今述べたすべての理由から、コンテナを使用してこのようなことを行う方が簡単です。 ですから、私もエンタープライズアーキテクトとして、ベストプラクティスを信じています。 私はコンテナを使って多くの新しい開発を行ってきましたが、これらのベストプラクティスを信じています。

• 各コンテナーは 1 つのことを行い、それをうまく行う必要があります。 同じマシンで多数のコンテナを実行できるのに、なぜ同じコンテナに多数の異なるものを配置するのでしょうか? 1 つのプロセスで 1 つのことを行うことができます。 それは素晴らしいことです。
• 開発ツールを運用環境に出荷しないでください。 これはやめてください。 開発ツールを入手した場合は、開発に限定してください。 本番環境には入れないでください。 本番環境に導入すると、ハッカーの攻撃対象領域が拡大するだけです。
• 可能な限り画像のサイズを小さくします。 ですから、コンテナに不要なものを取り出します。 アーティファクトをビルドしている場合は、イメージを構築するときにそれらを取り除きます。 アプリケーションの実行に必要なものだけを含めます。 そのため、アプリケーションの実行に必要のないものがある場合は、運用イメージに含めるべきではありません。
• そして最後に、シンプルに始めて、必要に応じてより複雑にします。 最も複雑なアーキテクチャから始めて、徐々に作業を進める必要はありません。 コンテナを使用すると、シンプルに始めて簡単に移行できます。

さて、ここで少し時間を取って、これについて話しましょう。 エンタープライズ アーキテクトは、すべての新しい開発を行っているため、これは簡単です。 新しい開発を行うときはいつでも、これらすべてが簡単です。 それはすべて簡単です。 使い勝手はとても良いです。 しかし、ここで、エンタープライズアーキテクトが手に入れた新しいプロジェクトについて話しましょう。 そこで、この人が取り組む新しいプロジェクトを紹介します。 私はJavaの人間なので、Javaの例を見ていきます。

そのため、このアプリケーションは 2010 年に最初に運用環境にデプロイされ、時間の経過とともに機能が追加されました。 このアプリケーションは、ビジネスにとってミッションクリティカルです。 だから、あなたはそれを取り除くのではありません。 そのアプリケーションは、あなたがそれを修正するかどうかに関してそこにとどまっています。 そこで、Java仮想マシンから始めます。 次に、その上にJava EEサービスを備えた大きなアプリケーションサーバーを追加します。 そして、その上にSpringフレームワークを追加します。 そして、はい、私が質問を受ける前に、はい、 2010年にさかのぼって、人々は実際にJava EEとSpringを同時に使用していました。 ああ、ねえ、私は私のログ4jのファンのために叫び声を上げることができますか? ああ、わかりました、ログ4jのジョークには早すぎます。 まぁ、それでいいんですけどね。 つまり、ロガーに実行コードをリモートでダウンロードする機能を与えることが悪いことだと誰が知っていたでしょうか? お願いだから。

さて、検索エンジンが見えてきたので、さらに多くのJavaライブラリがあります。 さらに 10 個の jar ファイル、さらに 100 個の jar ファイルを追加してみませんか? すべて順調です。 そして、その上にさらに多くのサポートファイルがあります。 そして最後に、ビジネスアプリケーションがあります。 そのため、eコマースJavaアプリケーションには、検索、在庫、販売、CRMがあり、レポート機能とサポート機能がすべて組み込まれています。 それで、あなたは自問自答しています、なぜ誰かがそんなことをするのですか? 次に、コンウェイの法則を思い出していただきたいのですが、この法則では、組織はその組織に似たアプリケーションを構築するというものです。 こういうことが起こるんですね。

もちろん、これはエンタープライズ アプリケーションであるため、モノと統合する必要があります。 そのため、SOAPを介して呼び出される外部Webサービスがあります。 バックエンドへの MQ 呼び出しがあり、複数のバックエンド データベースと通信しています。 つまり、このアプリケーションはファイルシステム上に 12 .5ギガ置かれているのです。

アプリケーションのビジネスへの影響

これが私たちのアプリケーションです。 私たちは言われてきました:それを理解してください。 そこで、このアプリケーションのビジネスへの影響と、私たちが把握するように言われたことは次のとおりです。

• デプロイの頻度。 新しいリリースを実際に出すのは、少なくとも四半期ごとです。 新しいリリースを世に送り出すのに6か月以上かかる可能性があります。
• そのため、変更のリードタイムは少なくともその程度です。 そして、私たちは大きな変化について話しているのではありません。 フィールドを移動したり、テキストを追加したりする場合でも、その変更を行うのに3か月、6か月かかります。
• スケーリング。 これをスケーリングする場合は、新しいインスタンス全体を削除し、スケールアップする必要があるたびに水平方向にスケーリングします。
• 信頼性が低い。 Javaの人なら誰でもこれを理解していますが、このアプリケーションの最小の機能関数でさえ、メモリリークが発生すると、アプリケーション全体に影響を与えます。 そのため、1つの小さなことがアプリケーション全体をダウンさせる可能性があります。
• そして、より複雑な開発者エクスペリエンス。 この巨大なモデルがすべてまとまっているため、開発者はコードをローカルで簡単にテストできません。 テストや特定の変更が必要な場合、 12 ギガ半のファイルを扱うのは簡単ではありません。 コードをテスト環境にプッシュする必要がある場合があり、これはフィードバック ループが遅くなり、プロセス全体が遅くなることを意味します。 そして、この複雑さこそが、導入頻度の低さと変更のリードタイムの長期化の原因となっています。
• これはすべて、より高いコストを意味します。 つまり、より大きなチームになるということです。 つまり、運用コストが高くなります。 つまり、ハードウェアが増えるということです。 これが、このアプリケーションを持つことによるビジネスへの影響であり、このエンタープライズ アーキテクトがそれについて何かをするように言われた理由です。

これが私たちのアプリケーションです。 私たちは、これをコンテナ化して、それが私たちのために何をもたらすかを見ようとしていると思います。 では、ベストプラクティスに戻りましょう。

最初のベスト プラクティスは、各コンテナーが 1 つのことを実行し、適切に動作することでした。 いいえ、これはさまざまなプロセスで大量の機能を備えているため、私たちはそれをしていません。 開発ツールを運用環境に出荷しないでください。 私にはわかりませんでした。 私はこのプロジェクトに配属されました。 開発者ツールが何なのか、何が入っていないのかわかりません。 知りません。 可能な限り画像のサイズを小さくします。 これは 12 年半のライブです。 何を期待しますか? アプリケーションの実行に必要なものだけを含めます。 文字通り何百ものjarファイルがあります。 どれが実際に使われていて、どれが使われていないのかはわかりません。 シンプルに始めて、必要に応じて複雑にします。 はい大丈夫です。

そこで、このアプリケーションをコンテナ化するこれらのベスト プラクティスのほとんどすべてを破ります。 そこで問題になるのは、この大きなモデルをDockerコンテナに詰め込めるのかということです。 そして、答えは簡単です はい、できます。 コンテナは、結局のところ、単に孤立したプロセスです。 OCI仕様には、特定のサイズにしかできない、特定の数のプロセスしか持てない、特定の量のRAMしか必要としない、などというものはありません。
これは絶対に容器に入れることができます。

さて、昨日のAI/MLワークショップに来られた方はいらっしゃいますか? カップルを手に入れました。 ですから、もしあなたがそのワークショップに参加していたのなら、昨日、私たちがプッシュしていたギグサイズ以上の個々のレイヤーを持つ画像を使っていたので 12 これに対する答えはすでにわかっていたでしょう。 さて、まったく別の質問は、それらのことがそれほど大きくなるべきかということです。 それは別の会話です。 しかし、間違いなく、人々は日常的にこのサイズ以上の画像で作業しています。 さて、私はここにいます。 私はDockerファイルを書きました。 JVMNをコピーし、アプリケーションサーバーをコピーし、これらすべてのjar、耳、戦争をこのものにコピーしました。 アプリケーション コードをコピーし、アプリケーションをビルドし、コンテナーに入れました。 さて、それは私が思っていたよりもずっと簡単でした。 ウェイターにチップを渡して、素晴らしい一日をお過ごしください。 ありがとうございます。 いいえ、まだあります。

利点の再検討

それでは、先に進みましょう。 では、これを行う利点は何でしょうか? そもそもなんでこんなの入れ物入れたんだろう? これは、モノリスをコンテナに入れるために実際に何をしているのでしょうか? さて、メリットに戻りましょう。

• コンテナーはプロセス レベルの分離を提供するため、同じハードウェアにより多くのものを詰め込むことができます。 はい、それはこのモノリスでも機能します。
• コンテナにはすべての依存関係が含まれているため、私のマシンでは動作しなくなりました。 はい、私は自分のマシンに 10 つの異なるバージョンのJVMを持っている可能性があり、これがコンテナで実行されている場合でも機能します。 私のコンテナは、ホストマシンにあるものに関して機能します。
• コンテナを使用すると、ディストリビューションを簡単に移動できます。 そう、 12 年半のギグを拾って、別のマシンに落とすと、同じように動くんだ。
• コンテナはOCI標準を使用します。 はい、私のコンテナは、さまざまなクラウドプロバイダー、プライベートクラウド、パブリッククラウド、およびすべてのDevOpsツールで役立ちます。
• そうすれば、開発者はコンテナをより快適に操作できます。 はい、モノリスであっても、ホスト上でローカルで実行されている場合よりも優れたエクスペリエンスが得られます。

近代化

さて、ここからは、モノリシックなアプリケーションのモダナイゼーションとコンテナについて見ていきましょう。 さて、このセクションから得られることが 1 つあるとすれば、それは、アプリケーションを最新化する正しい方法は 1 つではないということです。 組織によって異なる場合があります。 これは、アプリケーションレベルによって異なる場合があります。 さまざまな戦略が何であるか、それをトリアージする方法、実際にモダナイゼーションを行うためのさまざまなパターンを把握する必要があり、それは特定の組織、特定の文化、特定のアプリに対応する必要があります。 私はあなたにいくつかの異なる部分を示すつもりですが、これがあなたにとってうまくいくものを理解するのは本当にあなた次第です。

モダナイゼーション戦略のいくつかについてお話ししましょう。 そこで、約10年前にガートナー社が提唱した「5つのR」というものについてお話しします。 さて、Webでモダナイゼーション戦略を検索すると、すべてのコンサルティング会社がこれのバージョンを持っていることがわかります。 私は6 Rバージョン、7 Rバージョン、9 Rバージョンを見ましたが、これの 10 Rバージョンを思いつくことができれば、お金を稼ぐことができると確信しています。 しかし、これらを見ていきましょう。

• 1 つ目はリホストです。 これは最小限で、変更、リフトアンドシフトはありません。 これは、それがインストールされているハードウェアからそれを拾い上げ、他の何かにドロップすることです。
• 次はリファクタリングです。 つまり、これは軽い修正、適用、おそらく技術的負債の返済です。
• 次はReArchitectです。 次に、アプリケーションを大幅に変更し、アプリケーションを分割または分解しています。
• 次に、再構築に着手します。 そのため、アプリケーションをゼロから書き直し、アプリケーションを再設計しています。
• そして最後に、このプレゼンテーションでは取り上げませんが、アプリケーション全体を別のものに置き換えることができる場合は、そうしてください。

大丈夫です。 では、アプリケーションをモダナイズするための考慮事項は何でしょうか。 これらの戦略を使用する場合、この特定のアプリケーションに対してどの戦略または戦略の組み合わせが機能しますか? そこで、考慮すべき点をいくつか紹介します。

• ビジネス上の優先事項は何か? ビジネスは何をしたいのか、そしてこのアプリケーションのモダナイゼーションはそれにどのように適合するのか? では、ビジネスリーダーが立ち上がって、私たちのビジネスの優先事項はこのアプリケーションを最新化することであると言ったのは誰ですか? 私が今までにそれが起こったのを見たのは、そのアプリケーションがあまりにもひどい動作をしていて、それ自体がニュースを引き起こしているときだけです。 そして、そのとき、ビジネスは実際に立ち上がり、何かをしなければならないと言います。 そうでなければ、誰もそんなことは言わないでしょう。 彼らは、より多くの顧客、より多くの収益性、新しい機能、そのようなものを追加したいと言うでしょう。 では、そのアプリケーションをモダナイズすることは、これらのビジネス上の優先事項にどのように適合するのでしょうか?

• アプリケーションに関する知識。 このアプリケーションがどのように機能し、どのように採用されているかを本当に理解している人はどこかにいますか? ですから、これは 10 年以上前に建てられたものであることを忘れないでください。 それを建てた人々はまだここにいますか? 彼らはこの仕組みを本当に理解しているのでしょうか? それとも、誰もがそれをブラックボックスとして扱い、その端をつま先立ちでつま先立ちして、壊れないことを願っているのでしょうか?
• これに結びついているのが、アプリケーション技術スタックです。 13年前に使用していたのと同じテクノロジーをまだ使用していますか?あなたはまだJava EEをやっていますか、それともGolangか何か他のものに移りましたか?このアプリケーションを詳細に実際に作業する能力はまだありますか?
• アプリケーションの寿命。 ビジネスは現在の形でこのアプリケーションを必要としていますか、それともこの時点から移行しましたか? そして、それはモダナイゼーション戦略にどのように影響しますか?
• 組織の能力。 開発者、テスター、運用担当者には、それぞれ本業があります。 では、このモダナイゼーションを実際に行うための能力はどこにあるのでしょうか? それは、あなたがやるべき他のことと比較して、どのように機能するのでしょうか?
• そして最後に、コストとリスクです。 モノリスの運用にはコストとリスクが伴います。 また、これらのモダナイゼーション戦略にはコストとリスクが伴います。 それらのいくつかは、非常に大きなコストとリスクを持っています。 これらはすべて、アプリケーションをモダナイズする方法を実際に決定しようとしているときに避けなければならないことです。

リホスト

それでは始めましょう。 最初のオプションとして再ホストを行い、それがどうなるかを確認します。 そのため、コンテナ化はすぐに報われました。 私はこの容器を拾うことができました。 主要なクラウドプロバイダーのいずれかにドロップできます。 プライベートクラウドに置くことができました。 今の私には些細なことです。 そのコンテナは、上がったり下がったりします。 MQとデータベース用のプライベート・バック・チャネルをセットアップして完了です。 そのため、コンテナ化はすでに成果を上げています。

リファクタリング

それでは、リファクタリングに移りましょう。 さて、今回は楽勝を狙ってみようと思います。 技術的負債を少し減らし、アプリケーションにあまり影響を与えずに賢明な判断を下そうとします。 そこで、このケースでは、まず API の古い SOAP 呼び出しを休ませるように変更します。 そして、運用レポートをビジネス アプリケーションに組み込むことは、そもそも決して良いアイデアではなかったことを認識します。 そこで、その機能を削除して使用せず、別のコンテナーで実行されるサードパーティのレポート ツールに配置します。 また、これらのJavaライブラリのいくつかを調べて更新し、うまくいけば、この時点で企業によってサポートされる可能性のあるバージョン、またはコミュニティによってサポートされる可能性のあるバージョンに到達する予定です。 それに関連する技術的負債を少し返済します。 しかし、アプリケーションが何であるか、またはそれが何をするかについて大きな変更を加えているわけではありません。

リアーキテクト

よし、再設計だ。 したがって、この時点でいくつかの重要な変更を加えます。 だから、ここからが人生が楽しくなるところです。 では、なぜこれをサービスに分割するのでしょうか? ですから、アプリケーションを分割または分解するというアイデアについて話します。 それは実際に私に何を提供していますか? それでは、サービスの特徴についていくつか説明し、次にそれらの利点のいくつかについて話しましょう。

• そのため、サービスを個別にデプロイできます。 つまり、サービスは他のコンポーネントに依存する必要がありません。 彼らは自分で走り、生きることができます。
• これらは他のサービスと疎結合されています。 したがって、それらの間で呼び出すための何らかの仲介者またはAPIが必要です。
• これらは、ビジネス機能または機能によって定義されます。 では、ここでコンウェイの法則に戻りましょう。 サービスを定義するときは、これらのサービスがどのようなビジネス機能を担当し、どのような機能を担っているのかを理解する必要があり、どのような組織的な責任があるのかを理解する必要があります。
• 単一責任モード。 ですから、彼らは1つのことに責任があります。 さまざまなものを 1 つのサービスにまとめるのではなく、モデルが残っています。
• これらには、独自のビジネス ロジックとデータ管理が含まれています。 そのため、周囲のビジネスルールを理解し、その特定の機能領域に関連するもののデータ管理を理解しています。
• そして、それらはサービスまたはある種のAPIまたはブローカーを介して相互に通信します。

スコープ

次の質問は、サービスの適切なスコープは何かということです。 したがって、ここでいくつかの用語について話すことができることはわかっています。 そして、人々はこのことについてさまざまな用語を持っています。 これは私が使っているものです。 確かに、独自のバージョンがあれば、それは問題ありません。

• そのため、マクロサービスまたはモノリスと呼ばれるものがあります。 ここまでお話ししてきたのは、すべてが一緒にデプロイされるモノリスがあるということです。 すべてが緊密に結びついています。
• マイクロサービスがあります。 マイクロサービスという言葉は誰もが耳にしたことがあるでしょう。 ビジネスコンポーネントをカバーします。 そして独立して展開されます。 疎結合。 API経由で通信します。 かなりいいです。 ご存じのとおり、マイクロサービスには多くの機能と能力があります。
• しかし、他にもいくつかの選択肢があります。 多くのサービスがあります。 したがって、複数のマイクロサービスを、おそらくプロセスを介してビジネス機能にグループ化する場合、そのようなものはミニサービスと呼ぶことができます。
• そして、ナノサービス。 大丈夫です。 次に、特定のウィジェットまたはページ上の特定のものに取り掛かり、それを非常に細かい粒度のスコープにして、非常に小さくてデプロイ可能なものを用意します。

では、サービスの適切なスコープとは何でしょうか? 正しいスコープは 1 つではありません。 繰り返しになりますが、何をしようとしているかによって異なります。 適切なスコープとは、真の価値を提供するのに十分な大きさであり、大きくないスコープです。

モノリスに対するサービスの利点

さて、サービスとモノリスの利点について話しましょう。 これらの多くは非常に明白ですが、それらを見ていきます。 大丈夫です。

• 小規模な独立した開発チーム。 したがって、小規模なサービスがある場合は、これらのそれぞれに小さなチームを持つことができます。 モノリスで作業する 50 人や 100 人の代わりに、5 人から 10 人が個々のサービスで作業することができます。
• つまり、私には独立したリリーススケジュールがあります。 そのため、変更の市場投入までの時間が短縮されました。 これができれば、ビジネス上の利点になります。 リリーススケジュールを四半期ごとや 6 か月から 1 週間、1 時間以内に短縮できれば、大きな違いになります。
• サービスを個別にスケーリングします。 スケーリングが必要な特定のサービスがあり、アプリケーションの残りの部分ではスケーリングしない場合は、その 1 つのサービスをスケーリングし、残りのサービスはスケーリングしないようにすることができます。 これにより、リソースコストを大幅に節約できます。
• スコープの小さい開発者エクスペリエンス。 繰り返しになりますが、私たちは開発者のエクスペリエンスを向上させたいと考えています。 私たちは、人々がその間奏を簡単に行い、ローカルマシンで作業し、テストを行い、そのフィードバックをすぐに得ることができるようにして、生産性を向上させたいと考えています。
• ブルーグリーンデプロイ。 このアイデアは、同じサービスの複数のバージョンを同時に実行し、両方のバージョンについてすぐに運用フィードバックを得て、どちらがより適切に機能するかを確認できるというものです。 繰り返しになりますが、これができれば、ビジネス上の利点になります。 これにより、ビジネスに対するフィードバックが大幅に加速されます。
• サービスの再利用性。 これはサービスエリアの白鯨の一種です。 しかし、理想的には、購買サービス、税務サービス、在庫サービスなどがあり、そのサービスを異なるアプリケーション間で何度も再利用できるようにすることができます。
• 技術にとらわれないサービス。 今では、すべてを同じ言語で書く必要はありません。 すべてが Java EE である必要はありません。 実際には、さまざまなテクノロジー、さまざまなフレームワークをすべてアプリケーションのために連携させることができます。
• アプリケーションの信頼性の向上/制御障害モジュールの向上。 またはフェイルブート。 考えてみれば、何らかの理由で障害が発生している特定のサービスがある場合、そのサービスに障害が発生して障害モードに入る可能性があるからといって、アプリケーションの残りの部分に障害が発生するわけではありません。 一方、モノリスでは、Javaのメモリリークにより、すべてがダウンし、その時点で誰もが能力を失っています。

課題と落とし穴

さて、課題と落とし穴があります。 ですから、私は、サービスは素晴らしく、素晴らしいものであり、誰もがどこでも利用すべきだと言いました。 しかし、課題はあるのでしょうか? はい。

複雑性 — 1つ目は殺人鬼です。 これは絶対的な殺人者です。 これを計画しないと、複雑さが増します。 テクノロジーは複雑です。 プロセスが複雑です。 組織の複雑さは、サービス アーキテクチャに移行するときに計画し、理解する必要があります。 では、話を戻しましょう。 小規模な独立した開発チーム — あなたの組織はその準備ができていますか? それができる成熟度があるか? 独立したサービスのリリーススケジュール。 リリースプロセスを計画していますか? 彼らはそれを処理できますか? サービスを個別にスケーリングするブルーグリーンデプロイメントは、これを実現するためのテクノロジースタックです。 これらはすべて、実際にこれらの変更を行うときに考慮する必要があることです。

レイテンシー — はい、ネットワークホップは本物です。 つまり、モノリスで実行していて、ページをレンダリングしているとき、その特定のサービス内ですべて実行されているということです。 これで、特定のサービスがあまり高速に実行されていないと言えます。 いいです。 しかし、それはすべて 1 つのサービス内にあります。 一方、同じページをレンダリングするために 5 つのマイクロサービス、10 のマイクロサービス、または 50 のマイクロサービスがある場合は、これらの特定のサービスのそれぞれ間でネットワーク ホップを引き受けることになります。 そして、それは積み重なる実際のレイテンシーであり、考慮する必要があります。

分散型モノリス — このプレゼンテーションでコンウェイの法則について言及するのはこれで3回目です。 そのため、アプリケーションをサービスに委譲する場合、それらのサービスは互いに独立している必要があります。 これらは疎結合にする必要があります。 そうしないと、相互に大きく依存し、一緒にデプロイし、一緒にバージョン管理し、常に連携して動作しなければならない一連のサービスになってしまいます。
つまり、モノリスのネガティブな点とサービスアーキテクチャの複雑さをすべて備えた状況ができあがり、この2つを足し合わせたのです。 これは、人々がこれを行うときに実際に起こることです。 ですから、気をつけておかなければならないことです。

きめ細かすぎるサービス — すべてをサービスにしましょう。 ページ上のすべてのウィジェットをサービスにしましょう。 あらゆるサービス分野をつくりましょう。 いいえ。なぜでしょうか。 なぜそんなことをするのですか? サービスにしようとしているこの特定の機能に、サービスを作成することによって発生する実際の価値がない場合は、それをサービスにしないでください。 自分にとって意味のある、より大きなスコープを見つけてください。 繰り返しになりますが、サービスは、真の価値を提供するのに十分な大きさでなければなりません。 そうでない場合は、そのスコープをどの程度細かく作成しているかを確認する必要があります。

テクノロジーが目標です。 CEOが立ち上がって、私たちの目標はKubernetesに到達することだと言ったのは誰ですか? 私たちの目標は、Istioを実行することです。 誰も。 誰もそんなこと言わない。 誰もそんなこと言わないのはなぜ? なぜなら、テクノロジーがゴールではないからです。 テクノロジーは目標への手段です。 テクノロジーは、目標に到達するための手段です。 ですから、テクノロジーそのものが目標だと言われている状況に陥ったことがあるなら、それを修正して、ビジネス目標が何であるか、そして実際にどのように取り組んでいるかを理解する必要があります。

絞め殺しイチジク

次の質問は、モノリシックなアプリケーションをサービスに分割するにはどうすればよいかということです。 つまり、この大きなモノリスがあるのです。 サービスに行きたいです。 どうやってやるの? これを実現する方法に関する多くのデザインパターン、多くの記事、多くのブログ、その他多くのドキュメントがあります。 私はあなたに1つの方法を与えるつもりですが、それがそこにある唯一の方法だとは思わないでください。

ストラングラー イチジク パターンと呼ばれるモノリス分解戦略について説明します。 そして、その名前のせいで、それがどこから来たのか、なぜなのか、そういったことについて、いくつかの背景を説明する必要があります。 これは マーティン・ファウラーのウェブサイトからのものです。 そこに行って、この情報を見ることができます。 それで、彼は休暇中で、絞め殺しのイチジクを見ました。 絞め殺しイチジクは、実際に木の枝に種をまくイチジクです。 そして、彼らが何をするかというと、根を下って地面に伸び、実際に出発した木を取り囲み、木を窒息死させるのです。 彼らは基本的に、彼らが成長した木を殺します。

マーティンは、これをアプリケーションの素晴らしい比喩だと考えました。 アプリケーションを一から書き直すのではなく、実際に新しいサービスや新しいシステムを構築して、それらの新しいシステムやサービスが元のアプリケーションをゆっくりと締め付けていくのを待ってみてはいかがでしょうか。 これが、モノリスをサービスに分解するために使われてきたデザインパターンになりました。

サービスの識別

さて、まずはサービスを特定する必要があります。 モノリスからサービスを特定し、作成する必要があります。 最初に行うことは、論理コンポーネントを特定することです。 この特定のアプリケーション内で論理的に意味のあるグループ化は何ですか? 次に、これらのコンポーネント間の依存関係を理解します。 それらの依存関係は何ですか? それらはどの程度緊密に結合されていますか? 密結合されている場合、疎結合に変更する方法はありますか? これらのコンポーネントの一部が場合によっては同じことをしていることに気付くため、これらのコンポーネント間の機能の重複を検出または削除する必要があります。 それが済んだら、サービスと呼ぶコンポーネントのグループを作成できます。 次に、マクロからナノまで、これらのサービスの粒度を決定できます。 そして、それらのサービスをリモートで呼び出すためのAPIまたはブローカーを持つことができます。

この例では、その最初のいくつかの手順を実行しました。 この時点では、このアプリケーションのコードをまったく変更していないことに注意してください。 私が行ったのは、コンポーネントを特定することです。 私はそれらの間の依存関係を理解し、それらのコンポーネントをサービスに論理的にグループ化しました。 これで、注文、顧客、在庫、検索、支払い、サポートケースができました。

最初に行うことは、HTTP プロキシを独自のコンテナーにドロップして、ここの横にドロップすることです。 これにより、これらのサービスをリモートで呼び出して、それらを分割できるようになります。 次に、最初に分割するサービスになるのにふさわしいと思われる特定のサービスを選択します。 ですから、支払いは、より簡単で自己完結型で、分割できるものと考えるつもりです。 だから私はそれを取るつもりです、私はそれをそれ自身の容器に入れるつもりです。 それが済んだら、支払いの要求をその新しいコンテナーにリダイレクトし始めることができます。 そして、古いコンテナから支払い機能を削除できます。 ここで重要なのは、これはメインコンテナにあったのと同じコードであるということです。 APIによって呼び出されるものにする以外は変更していません。

さらに一歩進んで、これらの特定のサービスの残りの部分を調べて、それらを分割することができます。 そのため、それぞれが独自のコンテナを実行しています。 また、以前にここで実行していたレポートコンテナもあります。 さて、もう 1 つここで注意しておきたいのは、この特定の図では示していませんが、機能を変更していないため、これらのコンテナーのそれぞれに完全な Java EE サーバー、Spring のもの、すべての Java ライブラリーなどが含まれています。 私は単にサービスのメリットを得るためにそれを分割しただけですが、テクノロジースタックは変更していません。

建て直す

さあ、いよいよ再建に取り掛かります。 アプリケーションを書き直し、再設計します。 これで、新しい紙ができました。 今回はちゃんとやるつもりです。 私たちはすべての現代的なものを使うつもりです。 すごいことになりそうだ。 これをやり直せば、アプリケーションが何であるか、何をするか、どのフレームワークを使用しているか、そういった類のものをすべて変えることができます。 こうすることで、例えばこんな感じのものが出来上がります。

だから今、私はたくさんの異なるサービスを持っています。 Golangで書かれたものがあるのは、それが現在の技術スタックだからです。 レビューやディスカッション、ソーシャルメディアの統合のために、PHPで書かれた既存のものがいくつかあります。 CRMに使用しているサードパーティがあります。 検索に使います。 レポートに使います。 カスタマーサクセスに使うAI/MLチャットボットと、Rustで使うインベントリモジュールがあります。

さて、ご存じのとおり、この時点では可能性は無限大です。 アプリケーションを最初から書き直す場合は、変更したいものをすべて変更すればよいのです。 これは明らかに、最も時間とコストのかかるオプションですが、実行していることに最も柔軟性があります。 それぞれが独自のコンテナに入っているのがわかると思います。

さて、ここまで、さまざまなモダナイゼーション戦略について見てきました。 置換については説明していませんが、繰り返しになりますが、置換は全体を置き換えるだけなので、置換については説明していません。

さて、私たちがどこにいるのかをまとめます。 モノリシックなアプリケーションはまだたくさんあります。 これらのアプリケーションのモダナイゼーションは、今後何年にもわたって続くでしょう。 すべてのアプリケーションだと思っている人は、この時点でモダナイズされています。 申し訳ありませんが、あなたは私が持っている多くの顧客と話していません。

モダナイゼーションへの正しい道筋は1つではありません。 組織と特定のアプリケーションに最適なパスを決定する必要があります。 コンテナーは、そのジャーニーのどの段階にあってもモダナイゼーション プロセスに役立ち、コンテナーは、モデルであるかマイクロサービスであるかに関係なく、アプリケーションに役立ちます。

ありがとうございます。 もしあれば、誰かが質問するかもしれない場合に備えて、マイクを手に入れたいです。 みんなが一斉に飛び上がらないように。 さて、みんなありがとう。

質疑応答

問。 どなたか、話したいモノリスをお持ちの方はいらっしゃいますか?

はい、問題は、アプリケーションをサービスに分解することについて話すとき、データベースやデータストアはどうですか? そこでは、いくつかの異なる選択肢があります。 マイクロサービスがデータベースと対話できる十分な知識を持っていることを前提として、データベースをそのまま使用し続けることができます。 ユーザーを騙すことができる複数のサービスを必要とするデータ行が書き込まれている場合は、それを機能させるために何らかの変換レイヤーが必要になる可能性があります。 または、オプションBは、データベースをマイクロサービスに移動するときに、データベースを小さなデータストアに分割し始めることができるということです。 繰り返しになりますが、具体的な例を見ずに何とも言えませんが、これらのオプションはどちらも、何をしているかに応じて可能です。

そこで別の質問がありました。 問題は、私の理解が正しければ、アプリケーションを小さなコンポーネントにモデル化または分割するときに、それらの小さなコンポーネントごとにオペレーティング システムが必要なのかということです。 答えはイエスです。 コンテナーがモノリスであるかマイクロサービスであるかに関係なく、コンテナーであるためには、他のライブラリなどの依存関係が必要であり、Linux カーネルまたは Windows サービスで実行されます。 したがって、はい、アプリケーションのサイズに関係なく、これらの要件は引き続き残ります。

次の質問は、アプリケーションを分割した場合、ディスク容量が全体的に大きくなるかどうかです。 小規模なサービスの考え方は、ライブラリなどに関する限り、それぞれが同じ要件を持つべきではないということです。 したがって、理想的には、より小さくする必要があります。 さて、依存関係について心配しなければ、もしあなたが「私はそれについて心配するつもりはない」と言うなら、はい、他のすべてのコンポーネントは元のコンポーネントよりも大きくなります。 はい、しかし、サービスを作成することには、ファイル システムのサイズ以外にも利点があります。

他にご質問はございますか? はい。 質問を言い直させてください。 なぜ最初に決済サービスを選んだのか、また、そもそも特定のサービスを選ぶべきことは何ですか? そして、私が支払いを選んだ理由は、基本的に支払い呼び出しが私の例では、1つのリターンで使用されているため、アプリケーションの他の部分からより分離されていると感じたからです。 つまり、APIは比較的単純で、簡単に手に取って移動できるということです。 私が使用していた基準はこれだけですが、明らかに特定のアプリケーションについては、他の基準も確認する必要があるかもしれません。

次の質問は、アプリケーションを 25 つの異なるサービスに分割すると、突然、 25 つの異なるサービスの障害状態について心配し始める必要があるということです。 25つの異なるサービス間でのテストについて心配し始める必要があります。開発者のワークステーションで 25 つの異なるサービスを実行できるかどうか、心配し始める必要があります。 これらはすべて本当の懸念事項です。 これらはすべて、実際に行って理解しなければならないことです。

そのため、前にも述べたように、アプリケーションを異なるサービスに分割するたびに複雑さが生じます。 そして、それはあなたが考えなければならないことです。 そして、どのフレームワークを使うか、テストフレームワーク、これらの種類のものを処理するための他のプロセスフレームワークについて考える必要があります。 これらは本当に心配です。 「これをやればすべてうまくいく」という単純な答えはありません。 ただし、アプリケーションを分割する際には、これらのことを考慮する必要があります。 また、作成するサービスの数を細かくしすぎない理由もいくつかあります。

他に質問はありますか? はい。 そこで問題となるのは、コンプライアンスとポリシーに関するもので、分割して適用することがそれにどのような影響を与えるかということです。 例えば、決済モジュールとそれに対するPCIの準拠について考えると、それを各モノリスにエンコードすることで、各モノリスはその特定の標準に準拠する必要があります。 そして、その標準が変われば、それらのアプリケーションも一つ一つ変わらなければなりません。 一方、サービスにそれが含まれていて、それが含まれている場合は、その特定の仕様に準拠する必要がある場所が 1 つあります。 状況が変われば、1か所で変更され、誰もが再利用できるようになります。 ですから、そのようにすることには利点があります。 しかし、繰り返しになりますが、それも説明しなければならない複雑さがあります。

ほかに何か。彼らを唖然とさせて沈黙させた。 大丈夫です。 ありがとうございました。

さらに詳しく

• Docker を使ってみる
• Docker デスクトップの最新リリースを入手します。
• コンテナとは
• 質問がありますか? Docker コミュニティがお手伝いします。
• Docker は初めてですか? さっそく始めましょう。