Goテクノロジースタックに基づくマイクロサービス構築

大規模システムのマイクロサービス構築では、システムは多数のモジュールに分割されます。これらのモジュールはさまざまな機能を担当し、システムに統合されて最終的に豊富な機能を提供します。この形式の構築では、開発者は通常、モジュール間の結合によって生じる追加の開発コストを削減するために、モジュールの機能を可能な限り分離することに重点を置きます。同時に、マイクロサービスは、これらの多数のサービス システムをどのように展開し、どのように運用および保守するかといった新たな問題に直面しています。

この記事の素材は、開発における当社のベストプラクティス事例の一部から引用したものです。開発、監視、ログ記録の観点から、Go テクノロジー スタックに基づくマイクロサービスの構築に関する当社の経験の一部を紹介します。

発達

マイクロサービスの開発中は、さまざまなモジュールが異なる開発者によって管理され、明確に定義されたインターフェースが開発者の作業タスクを決定するのに役立ちます。最終的なシステムでは、ビジネス リクエストに複数のインターフェイス呼び出しが含まれる場合があります。リモート インターフェイスを正確かつ明確に呼び出す方法も大きな課題です。これらの問題に対して、プロトコルの策定と呼び出しを担当する gRPC を使用しました。

従来のマイクロサービスでは通常、モジュール間の呼び出しに http プロトコルが使用されます。しかし、私たちのマイクロサービス構築では、呼び出しを行うために Google が立ち上げた gRPC フレームワークを選択しました。次の表は、http rpc フレームワークと gRPC の機能を比較したものです。

gRPC インターフェースは Protobuf3 を使用して定義する必要があり、静的コンパイル後に正常に呼び出すことができます。この機能により、インターフェースの変更によって発生する通信コストが削減されます。 HTTP RPC を使用する場合、インターフェースを変更するには、まずインターフェース ドキュメントを変更し、次に呼び出し元に通知する必要があります。呼び出し側が時間内に変更を行わない場合、サービスが実行されるまでエラーが検出されない可能性があります。 gRPC のモデルでは、インターフェースの変更によって発生したエラーがコンパイル中に排除されることが保証されます。

パフォーマンスの面では、gRPC は従来の http rpc プロトコルに比べて大幅に向上しています (この評価によると、gRPC は 10 倍高速です)。 gRPC は送信に http 2 プロトコルを使用します。 http 1.1 と比較すると、http 2 は TCP 接続を再利用し、各リクエストに対して TCP 接続を確立するオーバーヘッドを削減します。業界では、単純にパフォーマンスを追求する場合、TCP プロトコル上に構築された RPC プロトコル (thrift など) を選択するのが一般的ですが、4 層プロトコルでは一部の伝送制御を都合よく実行できないことに注意してください。それに比べて、gRPC は http ヘッダーに制御フィールドを配置することができ、nginx などのプロキシ サーバーを使用することで、転送/グレースケールなどの機能を簡単に実装できます。

次に、関連する開発プロセスを簡素化するために、gRPC のいくつかの機能をどのように実際に使用するかに焦点を当てましょう。

1. コンテキストを使用してリクエストのライフサイクルを制御する

gRPC の Go 言語実装では、各 rpc リクエストの最初のパラメーターは context です。 http2 プロトコルはコンテキストをヘッダーに配置し、リンクに沿って渡すため、リクエストごとに有効期限を設定できます。タイムアウトが発生すると、イニシエーターは待機を終了し、エラーを返します。

 ctx := context.Background() // 空のコンテキスト
ctx, cancel = context.WithTimeout(ctx, 5* time . Second ) です。
延期キャンセル( )
 grpc.CallServiveX(ctx, arg1)

上記のコードでは、イニシエーターは約 5 秒の待機時間を設定します。リモート呼び出しが 5 秒以内に返されない場合、イニシエーターはエラーを報告します。

タイムアウトを追加することに加えて、コンテキストでは他のコンテンツを追加することもできます。以下では、コンテキストの別の素晴らしい使用例を見ていきます。

2. TLSを使用してアクセス制御を実装する

gRPC は TLS 証明書機能を統合し、非常に完全な権限制御ソリューションを提供します。実際には、システムにサービス A があるとします。ユーザーの機密コンテンツを操作する役割を担っているため、A がシステム内の他のサービスによって悪用されないようにする必要があります。悪用を防ぐために、自己署名のセカンダリ証明書システムを設計しました。サービス A は自己署名ルート証明書を持ち、A を呼び出す各サービスにセカンダリ証明書を発行します。このように、A のサービスへのすべての呼び出しは A によって承認される必要があり、A は各リクエストの呼び出し元を識別することもできるため、ログ記録やトラフィック制御などの操作を実行するのに非常に便利です。

3. トレースを使用してオンラインでリクエストを追跡する

gRPC にはリクエストをトレースするためのトレース システムが組み込まれており、過去 10 件のリクエストの詳細なログ情報を追跡し、すべてのリクエストの統計を記録できます。

リクエストにトレース ログを追加すると、トレース システムによって最後の 10 件のリクエストのログが記録されます。下の図に示す例は、トレース ログにビジネス データ トラッキングを追加する例です。

マクロレベルでは、トレース システムは、リクエストの数、さまざまなリクエスト時間に基づく統計の分布など、リクエストの統計を記録します。

このシステムは http サービスを公開しており、実行時にデバッグ スイッチを使用して必要に応じてオンまたはオフにして、リソースの消費を削減できることに注意してください。

モニター

1. 監視指標を決定する

システム全体の監視システムを構築するという課題に直面したとき、私たちが最初に直面した問題は、何を監視するかということでした。この質問に対する回答として、GoogleSRE という本には非常に詳細な回答が記載されています。レイテンシ、トラフィック、エラー、飽和度という 4 つの重要な指標を監視できます。

レイテンシはリクエストにかかる時間を測定します。ロングテール効果を考慮すると、平均レイテンシをレイテンシの単一の指標として使用するだけでは十分ではないことに留意する必要があります。したがって、遅延の分布を理解するには、遅延の中央値の 90%、95%、99% の値が必要になります。より良い方法は、ヒストグラムを使用して遅延分布をカウントすることです。

トラフィックは、サービスが直面するリクエストの圧力を測定します。各 API のトラフィック統計は、システムのホットスポットを理解し、最適化に役立ちます。

エラー監視とは、エラーのあるリクエスト結果の統計を指します。同様に、各リクエストには異なるエラー コードがあり、異なるエラー コードの統計を収集する必要があります。このタイプの監視をアラート システムと組み合わせることで、エラーを早期に検出し、介入することができます。

飽和とは、主にシステム CPU とメモリの負荷監視を指します。この種の監視は、当社の拡張決定の基礎となります。

2. モニタリングの選択

監視ソリューションを選択する際には、主に 2 つの選択肢があります。1 つは独自の監視システムを構築すること、もう 1 つはオープン ソースの Prometheus システムを使用することです。 2 つのシステムの違いを以下の表に示します。

当社のシステム全体では 30 台の仮想マシンに約 100 個のコンテナが分散されていることを考慮すると、Prometheus の単一マシン ストレージはボトルネックにはなりません。すべての履歴データを保持する必要はなく、独自のシステムを構築する利点だけでは魅力を感じません。逆に、4 つのゴールデン インジケーターから派生した多くのインジケーターをカウントできるようにしたいと考えているため、Prometheus の便利な DSL によってインジケーターの設計が大幅に簡素化されます。

最終的に、監視システムを構築するために Prometheus を選択しました。監視システム全体の枠組みを下図に示します。

各サービスは独自のアドレスを consul に登録します。 Prometheus は、監視対象のターゲット アドレスを Consul から自動的に取得し、これらのサービスから監視データを取得してローカル ストレージに保存します。 Prometheus の組み込み Web UI では、PromQL クエリ ステートメントを使用して統計情報をすばやく取得できます。同時に、クエリ ステートメントを Grafana に入力し、固定の監視インジケーターを使用して監視することもできます。

さらに、プラグイン AlertManager を使用すると、アラーム ルールを記述し、システムが異常な場合に携帯電話/電子メール/メールボックスにアラームを送信できます。

ログ

1. ログ形式

見落とされがちな問題は、ログ形式の選択方法です。適切なログ形式は、後続のツールでログ コンテンツをセグメント化し、ログ ストレージのインデックス作成を容易にするのに役立ちます。ログをファイルに出力するために logrus を使用します。 logrus ツールでサポートされているログ形式には、スペースで区切られた 1 行のテキスト形式や、json 形式などがあります。

テキストの書式設定

time =”2015-03-26T01:27:38-04:00″ level =debug g=”ビーチの観察を開始しました” animal=セイウチ number=8
時間=”2015-03-26T01:27:38-04:00″レベル=info メッセージ=”グループ 海から出てきたセイウチの動物=セイウチサイズ=10Json形式
{"animal":"セイウチ"," level ":"info","msg":"グループ セイウチが海から現れる”,”サイズ”:10,”時間”:”2014-03-10 19:57:38.562264131 -0400 EDT”}
 {" level ":"warning","msg":"グループの数がものすごく増えました!","number":122,"omg": true ," time ":"2014-03-10 19:57:38.562471297 -0400 EDT"}

2. エンドツーエンドリンクでの通話ログ収集

マイクロサービス アーキテクチャでは、ビジネス リクエストは複数のサービスに渡されます。エンドツーエンド リンクでログを収集すると、エラーが発生した特定の場所を特定するのに役立ちます。このシステムでは、リクエストのエントリ ポイントでグローバル ID を生成し、その ID を gRPC のコンテキストを介してリンクに渡します。さまざまなサービスのログを Graylog に収集し、クエリを実行するときに 1 つの ID を使用してリンク全体のログをクエリできます。

上の図では、セッション ID は、フルリンク取得を実行するための呼び出しチェーン全体の ID として使用されます。

まとめ

マイクロサービスで構築されたシステムでは、デプロイメント、スケジューリング、サービス検出、一貫性などの面で課題があります。 Go テクノロジー スタックには、これらの側面におけるベスト プラクティスがあります (docker、k8s、consul、etcd など)。特定のコンテンツに関する非常に完全なチュートリアルがすでにインターネット上に存在するため、ここではその方法をお教えしません。必要であれば自分で確認することもできます。