How are your microservices talking?の翻訳です。
2021年10月15日
あなたのマイクロサービスはどのように会話していますか？
マイクロサービス・アーキテクチャを実装する際の課題と、pub-subメッセージ伝送がどのように役立つかをご覧ください。
アプリの歴史を簡単に説明します：
- 古代：モノリシック・アプリケーション・アーキテクチャ、データ・ストアからユーザー・インターフェースまですべてを提供。
- 啓蒙時代：サービス指向アーキテクチャ。アプリケーションを多かれ少なかれ独立したサービスの塊に分割する。
- 現代：マイクロサービス・アーキテクチャ。柔軟性と障害への耐性を高めるために、サービスを構成要素にさらに分割する。
ここ数年の間に何らかのクラウドベースのアプリケーションを開発したり更新したりしたことがあるなら、時代遅れのサービス指向アーキテクチャではなく、マイクロサービス・アーキテクチャを使っている可能性が高い。では、何が違うのだろうか？
マイクロサービスとは何か？
マイクロサービスとは、アプリケーションを小さく疎結合なサービスとして構成するソフトウェア開発手法である。サービスそのものは最小の原子単位であり、それらが一緒になってアプリ全体の機能を構成する。マイクロサービスは1つのこと、つまりたった1つのことしかしません。
マイクロサービスは、機能の最小単位と考えることができ、独立してデプロイすることができ、再利用可能であり、HTTPのような様々なネットワークプロトコルを介して相互に通信することができる（詳細は後述する）。
今日、REST APIを公開するクラウドベースのアプリケーションのほとんどは、マイクロサービス上に構築されている（あるいは、実際にマイクロサービスそのものかもしれない）。これらのアーキテクチャはマイクロサービス・アーキテクチャと呼ばれる。
利点と課題
マイクロサービスの利点
より粒度の細かいサービス構造は、非常に大きなメリットをもたらす。クリティカルなコンポーネントは可用性の高い方法で構築することができ、クリティカルでないものがシステム全体をダウンさせることはありません。
マイクロサービスはある意味で相互依存関係にあるが、ポイント・ツー・ポイントのカスタム接続ではなく、明確に定義されたAPIを使用する。これは、スケーリングとアップデートに比類ない柔軟性をもたらす。
個々のマイクロサービスを置き換えるのは、システムの大きな塊を一度に置き換えるよりも迅速で簡単だ。これにより、新しいテクノロジーを試すことができ、最終的にニーズを満たさなくなる技術スタックに縛られることを避けることができます。
開発中、ソフトウェアの小さな塊で作業することは、最終的に継続的インテグレーションとデプロイの大きなメリットを享受し始めることができることを意味します。
マイクロサービスのデメリット
しかし、マイクロサービスの世界では、甘くて軽いことばかりではない。何かが壊れた時、誰かがログを調べなければならない。そして、たくさんのマイクロサービスはたくさんのログに等しい。たくさんのログがある。
テストとデプロイは、各マイクロサービスが個別に、そして一緒に機能することを検証しなければならないため、より複雑になる。これには、組織化された努力と適切なプロセスが必要だ。その結果、小規模な企業では、このような非常に粒度の細かいアプリケーションの開発に必要なすべてをまとめるのに苦労するかもしれない。
これらはすべて、大規模な人的課題である。これらはすべて、利用可能なリソースを増やし、適切に調整することで克服できる。しかし、主に技術的な課題として、マイクロサービスが通信する必要性があります。
どんなマイクロサービスも、仲間のマイクロサービスなしでは仕事をすることができない。人と同じように、コミュニケーションは重要だ。レイテンシーや通信の中断を避けるためにできる限りのことをしなければならないし、リクエストの処理に対応するためにコードベースを拡張しなければならないかもしれない。
次に、マイクロサービスの実装で使われるいくつかの通信パターンと、それに対応する方法を見てみましょう。
いくつかのマイクロサービス通信パターン
Sarah Romanの記事 "Introduction to Microservices Messaging Protocols "では、マイクロサービスによって、またマイクロサービス間で使用される通信パターンの分類法を優れた内訳を提供している：
同期
同期通信とは、イベントの送信者が処理と何らかの応答を待ち、その後に他のタスクに進むことです。これは一般的にREST呼び出しとして実装され、送信者がHTTPリクエストを送信し、サービスがこれを処理してHTTPレスポンスを返します。同期通信は、サービス間の緊密な結合を示唆している。
非同期
非同期通信とは、あるサービスが現在のタスクを終了するのを待つ必要がないことを意味する。送信者は必ずしも応答を待つ必要はなく、後で結果をポーリングするか、コールバック関数やアクションを記録します。これは通常、Apache KafkaやRabbitMQのようなメッセージバス上で行われる。非同期通信は、実際にはコンポーネントサービス間の緩い結合を呼び出します。
単一レシーバ
この場合、各リクエストは1つの送信者と1つの受信者を持つ。複数のリクエストがある場合、それらはずらされるべきである。なぜなら、 一つのレシーバーが一度にすべてを受け取って処理することはできないから である。この場合も、送り手と受け手の間の緊密な結合を示唆する。
複数のレシーバー
カテゴリが示すように、複数のリクエストを処理する複数のレシーバーが存在する。
これらの方法は（組み合わせて）MSA内でそれぞれの目的がありますが、分散アプリケーション内のマイクロサービス同士が非同期で複数のレシーバを経由して通信する場合、最も疎結合な配置になると考えています。このオプションは、送信者、送信時刻、プロトコル、受信者の間に厳密な依存関係がないことを意味します。
Pub-Sub
pub-sub通信メソッドは、この後者のメソッドを発展させたものです。送信者は単にイベントを送信するだけです - 送信すべきイベントがあるときはいつでも - そして各受信者はどのイベントを受信するかを非同期に選択します。
Apache Kafkaは、pub/subの最近の進化のひとつかもしれない。Apache Kafkaは、パブリッシュ・サブスクライブ・モデルを介してメッセージを受け渡し、プロデューサーと呼ばれるソフトウェア・コンポーネントが、トピックと呼ばれる分散ログ（概念的には、レコードが追加されるカテゴリ名のデータフィード）に時間順にイベントをパブリッシュ（追加）することで動作する。
コンシューマは、オフセット（トピック内のレコード番号）によって、これらのトピックから個別に購読するように構成される。この後者の考え方、つまりコンシューマは単純に何を消費するかを決めるという考え方は、パイプの最初にプロデューサーやシステムの他のコンポーネントに複雑なルーティングルールを設定しなければならないという複雑さを取り除く。
複数のレシーバーへの非同期通信が必要な場合、Apache Kafkaが有望だ。
なぜApache Kafkaなのか？
Apache Kafkaが優れた通信ソリューションである理由は？コンポーネントと通信の密結合の問題を解決し、監視可能で、より大きなコンポーネントをアトミックで粒度の細かい独立した再利用可能なサービスに分割することを容易にする。
コンシューマーが設定するルーティングルール
ルーティングルールがコンシューマーによって設定される場合 (pub-sub と Apache Kafka の一般的な機能)、データパイプ自体に複雑な機能を追加する必要はありません。これにより、コンポーネントをメッセージバス（および互い）から切り離し、依存関係を気にすることなく、独立して開発やテストを行うことができます。
非同期メッセージングの組み込みサポート
上記のすべてにより、コンポーネントを分離し、アプリケーションの特定の部分に集中することが合理的に簡単になります。非同期メッセージングを正しく使用すれば、イベントに同期することなくサービスの準備を整えることができるため、複雑さのもう1つのポイントを取り除くことができます。
高スループット/低レイテンシー
通信遅延の問題を心配する必要がなければ、より大きなサービスをより小さく、より原子的なものに分割することに安心感を持ちやすくなります。AivenのマネージドKafkaサービスはベンチマークされており、業界のどのホステッドサービスよりも高いスループットと低いレイテンシを特徴としています。
なぜApache Kafkaではないのですか？
Apache Kafkaはセットアップやメンテナンスが最も簡単なシステムではありません。Aivenは完全にホストされ、管理されたApache Kafkaを提供しており、アドオンやすべてのグッズを完備しています。
私たちの電子ブックを手に取り、Apache Kafkaの基本的なコンセプトを直接学んでください！
Apache Kafkaの何が優れているのか、他のイベントストリーミングツールとどう違うのか、詳しくご紹介します。
マネージド Apache Kafka があなたの生活を楽にする
Apache Kafkaのセットアップは難しい。オープンソースかプロプライエタリか、無料か有料かによって大きく異なります。将来の要件は何ですか？
バンドルされたソリューションを選択する場合、例えばバージョンやインストールタイプの選択は、将来ビジネスニーズが変化したときに、あなたを悩ませることになるかもしれません。
このような課題だけでも、マネージド・バージョンの説得力のある論拠となるでしょう。デプロイメント**、ハードウェア費用**、設定**の手間を省くことで、Kafkaのデプロイメントを元々意図していた開発に専念することができます。
さらに、マネージドは監視可能です。スループットを追跡していますか？カスタム・ロギングやモニタリングを行うための統合ポイントがアプリのどこにあるか心配する必要はありません。プロバイダーのKafkaバックエンドとメトリクス・インフラストラクチャを介して、アトミック・サービスの各スループットを監視するだけです。
自動スケーリング
アプリケーションがスケールしたとき、どのような問題が予想されるでしょうか？ボトルネック？レースコンディション？それらに対応するためのリファクタリングの混乱？
マネージドKafkaソリューションなら、データストリームのサイズが大きくなっても、自動的にスケールしてくれます。そのため、サービスをアトミックにリファクタリングするときに心配する必要はありません。また、サービス間のレイテンシを避けるためだけに、複雑な依存関係を持つblobスタイルのクラスタ化されたサービスをチームに維持させる必要もありません。
高可用性
Apache Kafkaはすでに高い可用性で知られているため、ミドルウェアをサポートするノードが1つダウンしたためにサービスが通信できなくなる心配はありません。
Kafkaは大量のデータを処理し、自動的に拡張できるため、データ負荷の増加に合わせてデータ処理能力を拡張することができます。また、マネージド・ソリューションには冗長性が組み込まれています。
一元化された煩わしさのない管理
自社でクラスターを管理する場合、インストール、アップデート、バージョン依存性の管理、関連する問題に縛られることが予想されます。Aiven for Apache Kafka®のようなマネージド・ソリューションがそのすべてを代行するため、お客様はコアビジネスに集中できます。
まとめ
Aiven for Apache Kafka®は、完全に管理された高スループットの分散メッセージングシステムで、ビルトイン監視機能を備えているため、サービスを通信手段から切り離し、開発を簡素化し、コアアプリケーションに集中することができます。
Aivenのサービスをまだお使いではありませんか？https://console.aiven.io/signupから無料トライアルにお申し込みください！
また、changelogやblogのRSSフィード、またはLinkedInやTwitterのアカウントをフォローし、製品や機能関連の最新情報をご確認ください。