これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
前回に続いて、2017年に開催されたSREcon17 Asia/Australiaでの講演「SRE Your gRPC--Building Reliable Distributed Systems」をもとに、マイクロサービス型のアプリケーションにおけるgRPCの役割を解説します。
この講演では、マイクロサービス・アーキテクチャーのアプリケーションを安定運用するためのガイドとして、次の6つの項目が上げられています。今回は、後半の3つについて説明します。
後半の1つ目にある「Degrade gracefully, don't guess.」は、問題発生時の動作に対する考え方です。前回と同様に、「Greeter」アプリケーションが「Translator FE」（翻訳サービス・フロントエンド）を呼び出して、それがさらに「Translation DB」を呼び出すという階層構造を考えます（図1）。
図1 コンポーネント間のサービスの連携（講演資料より抜粋）
図1では、Greeterアプリケーションからのリクエストを受けたTranslator FEが、バックエンドのTranslator DBにアクセスした際にエラーが発生した状況を示しています。この時、Translator FEはどのような動作をするべきでしょうか？ ―― リクエスト応答までの制限時間に余裕があれば、リトライ処理を実施することも考えられますが、その他には、バックエンドを使用せずに、簡易的な翻訳結果を返送するという方法もあります。このように、問題発生時に、サービスを完全に停止するのではなく、品質を下げてサービスを継続する手法を「Degraded mode」と呼びます。
そしてこの時、そのぞれの処理モードにおける処理時間とリソース使用量の見積もりが重要になります。正常動作時の応答時間だけではなく、Degraded mode、あるいは、エラーが発生した際の例外処理についても、それぞれ、サービス負荷に応じて処理時間やリソース使用量がどのように変化するかを事前に調べておきます。特に、例外処理の負荷が大きすぎると、リソース不足の状態でエラーが発生した際に、例外処理の負荷でさらに状況が悪化するようなことも起こりえます。Degraded modeでも対応できない状況が発生した場合のエラー処理については、問題判別に必要なログを出力するなど、最低限の処理に限定することが原則となります。この点について、冒頭の講演資料では、「When everything returns errors, fail fast and be cheap!」という標語が掲げられています（図2）。
図2 問題発生時の動作設計（講演資料より抜粋）
また、このような処理時間については、実際に負荷テストを行って確認することが原則となります。想定されるリクエスト量に対して、2倍、5倍、10倍といった負荷をかけて、実際の反応を観察します。本番のサービス環境では、必ず、何か想定外の現象が発生しますので、図2のタイトルに「don't guess」とあるように、根拠のない推測にもとづいた設計は避けなければなりません。
次の項目である「Measure all the things!」は、システムの稼働状況のモニタリングに関する考え方です。ここでは、CPU、メモリー、ディスクIOと言った、サーバーのリソースに関わる計測項目と、リクエスト数や正常応答数など、サービスの状態に関わる計測項目について触れられています（図3）
図3 モニタリングの基本項目（講演資料より抜粋）
まず、サーバーリソースに関しては、判断基準は明確です。サーバーリソースの不足は、間違いなく大きな問題を引き起こします。ハードウェア資源はサービス提供の根幹であり、そこには、物理的な限界があります。長期的な変化をモニタリングしながら、リソース追加の適切な計画を立てることが基本となります。
一方、サービスに関わる計測項目については、SLA（サービスレベル・アグリーメント）に応じて見る必要があります。たとえば、リクエストに対する応答時間は、多くの場合、「正常応答の99.9%は、〇〇秒以内である」といった形で定義されますので、単純に応答時間の平均だけを見ても意味がありません。応答時間全体の分布の様子、特に、応答時間が極端に長いものがどの程度あるかを把握することが大切です。
また、サーバー側がリクエストに応答を返して成功したと判断しても、その応答がクライアントに到達する前に、クライアント側でDeadlineに達してタイムアウトが発生するということもあり得ます。複数のサービスが階層的に連携するマイクロサービスの環境では、クライアントからのリクエストに起因する一連のリクエストをまとめてモニタリングする必要があります。特に、gRPCには、インターセプターと呼ばれる機構があり、これを利用すると、すべてのリクエスト処理に内部的な割り込みをかけてログを取得することができます。新規のリクエストにユニークなIDを割り当てて、後段のリクエストにメタデータとして引き渡すなどの作り込みをすれば、連携するリクエスト全体をひもづけて確認することも容易です。その他には、オープンソースのモニタリングツールであるPrometheusと連携するモジュールも用意されています。
そして最後の項目である「Best effort isn't.」では、リクエストにプライオリティを割り当てるQoS、あるいは、キャッシュの使用に関する議論がなされています。結論としては、これらの機構には独自の考慮点があるので、単純に使用すればよいというわけではなく、サービスの特性に応じて個別に有効性を判断する必要があります。図4のスライドでは、QoSやキャッシュに関するよくある質問に加えて、「よく聞き忘れる質問」として、"Oh really?"（それって本当？）という一言があげられています。どのような技術であれ、その動作原理を理解した上で利用することの大切さを示す一言ではないでしょうか。
図4 「よくある質問」と「よく聞き忘れる質問」（講演資料より抜粋）
今回は、SREcon17の講演資料をもとにして、マイクロサービス・アーキテクチャーの設計における考慮点の後半部分を説明しました。次回は、すこし話題を変えて、最近注目を集める、ディープラーニングによるイラスト生成に関する論文を紹介したいと思います。
Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
