マイクロサービス上級編: コンテナ実装と落とし穴回避ガイド

編集者注: コンテナとコンテナ オーケストレーション システムは、展開と運用のための基本的なプラットフォームにすぎません。開発者は、プラットフォーム上に展開されるアプリケーションにさらに注意を払う必要があります。コンテナ時代では、アプリケーション アーキテクチャは大きな変化を遂げました。アプリケーションがコンテナ プラットフォーム上で最大限の役割を果たすようにするには、マイクロサービスへの道を歩み始める必要があります。ただし、コンテナ実装のプロセスには多くの落とし穴があり、高度なマイクロサービスへの道にはより多くの経験が必要です。

マイクロサービス アーキテクチャは、モノリシック アーキテクチャと比較して大きな変化を遂げており、サイドカーなどの新しい設計パターンもいくつか生み出されています。マイクロサービス アプリケーションの開発は非常に困難な作業です。マイクロサービスをどのように分割するか、またマイクロサービスの粒度はどの程度細かくすべきかについて議論されているのをよく耳にします。初心者は「不安」な状態にあることが多いため、マイクロサービスの正しい道を進む方法を早急に知る必要があります。あるいは、マイクロサービス アプリケーションを設計および開発する方法をガイドするベスト プラクティスが必要です。

傲慢になったり、せっかちになったりせず、群衆に従わないでください。自分自身と敵を知ることによってのみ、あらゆる戦いに勝つことができます。

マイクロサービスについて語らないと時代遅れになってしまう時代になりましたが、IT 実務家としては、自分の興味から進み、「なぜ」についてもっと考え、流行に慌てて追随してはいけません。理由は簡単です。外がどんなに風が強く雨が降っていても、家が丈夫で安全で快適であれば、通常は取り壊して建て直す必要はありません。したがって、モノリシック アーキテクチャを引き続き使用するか、マイクロサービス アーキテクチャに切り替えるかを決定する前に、次の 2 つのことを行う必要があります。

まず、外部から 2 つのアーキテクチャの長所と短所を理解します。

2 つ目は、私たち自身のビジネスに目を向けることです。
1. モノリシック アーキテクチャにおける上記の問題のいくつかは、ビジネスに深刻な影響を及ぼしましたか?
2. 会社の新しいビジネス システムは、迅速な反復や柔軟性などの要件を満たす必要がありますか?
3. チーム内に DevOps の雰囲気はありますか?
4. 会社には新しい技術に取り組む十分な意欲と技術的余裕がありますか?

モノリシック アプリケーションとマイクロサービス アプリケーションのメリットとデメリットを理解し、自社のビジネス要件と実際の状況を分析し、最終的にマイクロサービス アーキテクチャへの移行を決定した後、これは一夜にして実行できるものではなく、段階的に段階的に実装する必要があることも明確にする必要があります。

盲目的に走ることはお勧めできません。徐々に進歩することでのみ、スムーズな前進につながります。

***段階的トライアル——新しいアプリケーションの開発

マイクロサービスに不慣れな企業にとっては、新しいアプリケーションから始めるのが適切なアプローチです。

最初のステップでは、 nginx ベースの Web サイトやドキュメントなど、新しい Web スケールのステートレス アプリケーションから開始することを選択できます。これらのアプリケーションは非常にシンプルで実装が簡単で、コンテナ プラットフォーム上でマイクロサービスのさまざまな機能を体験できます。ある程度の経験を積んだ後、 2 番目のステップは新しいステートフル アプリケーションを開発することです。ステートフル サービスの最大の課題はデータ管理です。重要な点は、以前のモノリシック アプリケーションの共有データベースとは異なり、マイクロサービス アプリケーション内の各サービスには「排他的に」独自のデータベースがあるということです。サービスは、互いのデータベースに直接アクセスするのではなく、API、イベント、またはメッセージングを通じて互いのデータにアクセスする必要があります。

言い換えれば、理想的なマイクロサービスとは、独自のデータをカプセル化し、API を通じてデータを公開して、データの結合を回避することです。この方法では、各マイクロサービスのデータ形式の変更が他のマイクロサービスのデータ呼び出しに影響を与えることはありません。大規模なエンタープライズモノリシックアプリケーションを開発およびアップグレードした経験のある人なら、このことを深く理解しているでしょう。誰かがデータベース スキーマを変更すると、アプリケーション全体が起動できなくなる可能性があり、チームの開発効率が大幅に低下します。

マイクロサービスアーキテクチャは完璧ではありません。自分に合ったソリューションが最善です。

マイクロサービスのデータは、強い一貫性を犠牲にして結果的な一貫性を通じて管理されており、それがデータの分割を非常に困難にしていることは理解しにくいことではありません。たとえば、異なるサービス間のデータ テーブルには、結合によってアクセスできなくなります。実際には、実行するのが困難であったり、非常に面倒であったりします。現在、マイクロサービス データ管理を提供する成熟した使いやすいライブラリやフレームワークはなく、一部のアプリケーションでは強力な一貫性が求められます。現時点では、このようなアプリケーションに対するマイクロサービスの実現可能性を完全に否定することはできません。適切な妥協、つまり「妥協」を行い、ミニサービスを採用すべきです。

ミニサービスは、開発と展開における独立性と俊敏性の点でマイクロサービスに似ていますが、マイクロサービスほど厳しい制約はありません。通常、ミニサービスは複数の機能を提供でき、これらの機能はデータベースを共有できます。現時点では、ハイブリッド アーキテクチャを恐れる必要はありません。また、マイクロサービス アプリケーションが「正統派」であるかどうかを恐れる必要もありません。 「大きく考え、小さく始め、素早く行動する」というのが私たちが従うべき哲学です。したがって、エンタープライズ アプリケーションにマイクロサービスとミニサービスの両方、または単一の部分 (マクロサービスと呼ぶこともできます) があってもかまいません。

電子商取引プラットフォームを例にとると、全体的なシナリオにおいて、ビジネス開発者が直面する主なプレッシャーは、フロントエンドの頻繁な変更から生じます。頻繁なプロモーション、販促、値下げなどの活動に対処する必要があるため、消費者に直面するフロントエンドのビジネスは迅速に反復される必要があります。消費者は継続的に商品を閲覧しますが、最終的にトランザクションを生成するリクエストの数は、商品情報を取得するためのリクエストの数よりもはるかに少なくなります。そこで、フロントエンド業務をステートレス化し、マイクロサービスを分割・分離することで、市場の変化に素早く対応し、柔軟に変更することが可能になります。

プラットフォーム全体をマイクロサービス レベルにできればもっと良いでしょうか?答えは「不確実」です。マイクロサービスの規模が一定レベルに達すると、管理と運用のプレッシャーが飛躍的に増大するからです。実際、一部のビジネスではマイクロサービスは必要ありません。たとえば、多くの電子商取引プラットフォームには 2B ビジネスがあり、ビジネス変更の頻度とプレッシャーは 2C ビジネスほど大きくありません。この場合、マクロサービスまたはミニサービスの形式で提供することも可能です。開発者は、アプリケーション アーキテクチャ全体のどの部分がマイクロサービスに適しているか、どの部分に緊急にマイクロサービスが必要なのかを分析する必要があります。

練習すれば完璧になる

上記の電子商取引の例では、ステートレス サービスについて説明しました。ステートレス サービスが期待される理由は、ステートレス アプリケーションはスケールアップとスケールダウンを迅速に実行でき、急増するトラフィックに対処でき、コンピューティング リソースを最も効率的に使用できるからです。無国籍であることは誇りであり、国籍を持つことは恥であるとよく耳にします。つまり、サービスは可能な限りステートレスである必要があります。たとえば、以前はユーザー セッション管理がビジネス ロジック モジュールで管理されていたため、これらのモジュールをステートレスに任意に拡張することができませんでした。これらのセッションの管理を抽出し、管理のために高可用性または分散キャッシュに格納することができます。ビジネス モジュールは API を呼び出してセッションを取得するため、これらのモジュールはステートレスになります。

しかし、これは、すべてのサービスが最善であるためにはステートレスでなければならないという意味ではありません。開発者はビジネスモデルと分割サービスを慎重に検討する必要があります。ステートレスであるためにステートレスにならないでください。ステートフルなサービスは常に存在するからです。

フェーズ 2 上級 - レガシー アプリケーションの変換

新しい機能の追加、既存の機能の迅速な反復など、慎重に検討した後でもレガシー アプリケーションをマイクロサービス化することに決めた場合は、いくつかのベスト プラクティスに従うのが最善です。当然ながら、ゼロから新しいシステムを開発するのは現実的ではなく、失敗する可能性も非常に高くなります。

***注:新しい機能ポイントは、元のモノリシック アプリケーションに基づいて開発することはできなくなり、マイクロサービス方式で開発する必要があります。ただし、このマイクロサービスは元のモノリシック アプリケーションの一部であるため、通常はモノリシック アプリケーションのデータにアクセスする必要があります。現時点では、両者の密結合を防ぐために、API を介してアクセスする必要があります。単一の部分では、API を提供するために Facade、Adapter、または Translator モードを使用するかどうかに関係なく、新しく追加されたマイクロサービス モジュールに対して疎結合のアクセス メソッドが提供されます。

2 番目に注目すべき点は、既存のモノリシック部分も徐々にマイクロサービスに変換できるということです。頻繁に変更され、ユーザーのニーズを満たすために迅速な反復が必要な部分を変換することを選択できます。数回の変換を経ると、元のモノリシック アプリケーション全体が置き換えられるか、残りのモノリシック部分は安定して変更されず、周囲の部分はすべてマイクロサービス ハイブリッド アーキテクチャに変換されます。

3番目のステージは柔軟性が高い - サービスメッシュ

サービス メッシュはマイクロサービス アーキテクチャの一部です。これは本質的には、トラフィックを傍受してポリシーを配置することでサービス間の通信を管理および最適化し、サービスをより堅牢で安全なものにする分散コンピューティング ミドルウェアです。通常、認証、承認、暗号化、サービス検出、リクエスト ルーティング、負荷分散、マイクロサービス間のサービス自己修復などの機能を提供します。

サービス メッシュは、マイクロサービス アプリケーションのデプロイに不可欠な部分です。これは、マイクロサービス アプリケーションが分散アプリケーションであるため、モノリシック アプリケーションよりも保守と管理がはるかに困難だからです。サービス メッシュは、サービスの管理と、サービスの堅牢性とセキュリティの向上に必要です。

そのため、サービスメッシュの選択も非常に重要です。 Istio と Spring Cloud のどちらを選ぶべきかで悩んでいるという話をよく聞きます。私たちは、Istio がサービス メッシュの開発方向であると信じています。アーキテクチャの観点から見ると、コントロール プレーンとデータ プレーンが分離され、開発者はアプリケーション ビジネス ロジックの開発に集中できるようになります。一方、複雑な分散アプリケーション サービス間の通信はサービス メッシュによって制御されます。 Spring Cloud は、アーキテクチャ設計の概念の点では後進的です。開発者がマイクロサービスを開発するときに、サーキットブレーカー、グレースケールリリース、負荷分散などの問題をコードに実装する方法を考える必要があると想像してみてください。負担は非常に重いです。さらに重要なのは、Spring Cloud タイプのサービス メッシュは Java 言語のみをサポートしており、これはマイクロサービスは任意の言語で開発できるという考え方に完全に反しており、ベンダー ロックインの疑いがあるということです。

Istio には多くの特徴的なラベルがあります。Kubernetes プラットフォームに自然に適しており、コードに侵入せず、言語バインディングがありません。しかし、Istio はまだ開発中であり、解決すべき問題がいくつか残っていることは認めざるを得ません。

• パフォーマンスはまだ理想的ではありません。 Istio に基づいて実装されたマイクロサービスは、仮想化や転送などの要因により、依然として過度のパフォーマンス損失に悩まされています。しかし、良い面としては、これがコミュニティによる継続的な改善の焦点であることがわかります。一方で、パフォーマンスを向上させるためにサービス メッシュのプロキシとして Cilium を使用するなど、誰もが効果的な試みを行っていることがわかります。
• 高い閾値。 Istio には優れたコントロール プレーンがありますが、開始コストは依然として非常に高くなります。多くの企業ユーザーはまだコンテナ変革の段階にあります。 Istio は見た目が複雑なため、企業の IT アーキテクチャにすぐに統合するのは困難です。
• 実用的な実装はほとんどありません。コミュニティは熱く、話題も非常に熱いですが、企業ユーザーは待っているか、試しているかのどちらかです。技術力のあるインターネット企業が Istio のコンポーネントを分解したり、変更したり、既存のマイクロサービスに接続したりしていることがわかります。

ガバナンス プラットフォームですが、コミュニティのメイン ブランチとの不一致という問題が発生するため、将来的にコミュニティとの一貫性を保つことができるかどうかについて懸念が生じます。メーカーによる製本という古い道をたどるかどうかはまだ分からない。 2018 年の KubeCon Shanghai で、Google の開発者が米国の 3 社による本番環境での Istio の成功例について説明したことは特筆に値します。同様のことは今後もどんどん起こるだろうと信じており、上海で開催される今年の KubeCon で Istio からのさらなる情報共有を期待しています。

Istio には前述の問題がありますが、1、2 年前の k8s、docker swarm、Mesos 間の競争と同様に、Istio のコミュニティも急速に成長していることも注目すべき点です。当時、k8s の強力なエコ活動は、最終的な勝利への良い基盤を築きました。私たちは、Istio がサービス メッシュ分野における k8s であり、将来的にこの分野で支配的な地位を獲得する可能性が高いと考えています。アプリケーションにマイクロサービスが増えると、サービス メッシュが非常に重要になります。さらに先を見据えると、FaaS がビジネス開発者の視野に入るにつれて、誰もがこの便利で柔軟な開発方法をますます享受するようになり、サービスの観点からの開発モデルがますます普及し、サービス メッシュ フレームワークがますます重要になるでしょう。

要約すると、Istio を介してマイクロサービス ガバナンス スクリーンを構築するには、学習曲線の開始点が高く、操作と保守が非常に面倒です。運用および保守担当者は、回路ブレーカー、電流制限、グレースケールリリースなどの機能の出力に重点を置きます。ただし、Istio では、まずコンポーネントをデプロイし、YAML を編集し、さまざまな抽象パラメータを理解する必要があります。これは、3D 映画を見る前に観客に 3D メガネを自分で組み立てるように求めるようなものです。したがって、マイクロサービスの進歩への道のりは長く困難なものとなります。企業には、ビジネスの観点からマイクロサービスを管理できるプラットフォーム レベルの商用製品が必要です。可視化ツールやプラットフォームは、ユーザーの学習コストと運用コストを削減し、ユーザーのビジネス価値出力能力を向上させ、デジタル時代におけるユーザーの中核競争力の再構築を支援します。