[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

CloudNative Days Tokyo 2023から、クラウドネイティブなトラブルシューティングのノウハウを紹介

2024年4月26日(金)
高橋 正和
CloudNative Days Tokyo 2023から、メルペイのSRE Tech Leadによるクラウドネイティブ環境におけるトラブルシューティングの手法を解説したセッションを紹介する。

2023年12月11日、12日の両日にハイブリッド形式で開催されたCloudNative Days Tokyo 2023から、株式会社メルペイのSRE Tech LeadのJunichiro Takagi氏が発表したセッションを紹介する。

株式会社メルペイのJunichiro Takagi氏

株式会社メルペイのJunichiro Takagi氏

タイトルは「CloudNative環境におけるトラブルシューティングガイド」。クラウドネイティブなWeb系システムの障害をどのように検知して対応するかについて、大規模クラウドネイティブサービスのSREとしての経験から得たノウハウが語られた。

オートスケーリングやオートヒーリングでも防げないトラブルもある

クラウドネイティブな環境では、オートスケーリングやオートヒーリングの機能などで、ある程度は負荷増大やインスタンスの障害に対応できる。

ただし、そうした環境でもトラブルは必ず起きる、というのが今回の話だ。

クラウドネイティブな環境でもトラブルは必ず起きる

クラウドネイティブな環境でもトラブルは必ず起きる

クラウドネイティブな環境でも防げないトラブルとしては、まずクラウド自体の障害がある。Takagi氏によると、実際には何分かサービスが使えないようなことはあまりなく、「数秒や数マイクロ秒などの短い時間での停止がちょこちょこあるような感じ」だという。

クラウドの障害

クラウドの障害

次にオートスケーリングで救えないケース。よくあるパターンとして、予想以上に負荷が上がった結果、事前に設定したオートスケールの上限値に達するケースや、クラウドリソースの上限(Quota)に達するケースがあるという。

またKubernetesでPodはすぐにオートスケールできても、ノードなどのオートスケールに数分の時間がかかるといったケースもある。

そのほか、CPU使用率をもとにオートスケールを設定していても、先にメモリ使用率が増えてしまい、オートスケールできずに再起動を繰り返すケースもある。

オートスケーリングで救えないケース

オートスケーリングで救えないケース

Kubernetesなどでは、障害を検知して自動的に問題のあるPodを再起動するオートヒーリングもある。このオートヒーリングでも、再起動しても同じ問題が起きてしまうケースなど、救えないケースもたくさんあるそうだ。

オートヒーリングで救えないケース

オートヒーリングで救えないケース

準備としてSLOを定義し、モニタリングやログなどを整備する

こうしたトラブルへの対応の前に、まずはトラブルに遭遇する前の準備の話だ。

準備0番としてTakagi氏が挙げたのは、「自分が運用しているシステムの構成を理解する」ことだ。大きなシステムでは、細かく把握するというより、リクエストがどのように来てどのようなシステムを経由してレスポンスを返すか、までのざっくりとした流れを理解している必要があるという。

準備0:自分が運用しているシステムの構成を理解する

準備0:自分が運用しているシステムの構成を理解する

準備1は、「自分たちのシステムの正常な状態を定義する」ことだ。SLO(Service Level Objective)を設定して、どこまで対応するかを決めるものだ。

ここで高すぎる目標を設定すると、アラートが増えて運用の負担も増えてしまうほか、クラウドサービスのSLAより高くても達成できない。「高すぎる目標には気をつけたほうがいい」とTakagi氏は語った。

準備1:自分たちのシステムの正常な状態を定義する

準備1:自分たちのシステムの正常な状態を定義する

準備2は、「トラブルを観測できるようにする」こと。設定したSLOを達成できているか、またSLOの構成要素となる各種メトリクスを取得し、必要に応じて通知できているかということだ。

準備2:トラブルを観測できるようにする

準備2:トラブルを観測できるようにする

準備3は、「観測できるようになったトラブルを調査できるようにする」こと。サービスのエラー率が増えているといったトラブルが観測されたときに、メトリクスやログ、トレーシングから原因を深掘りできるデータを用意する。「個人的には特にログが大事だと思っている」とTakagi氏は付け加えた。

準備3:トラブルを調査できるようにする

準備3:トラブルを調査できるようにする

把握:ほかの変化や境界の部分も確認する

こうした準備ができたうえで、次はトラブルシューティングだ。

トラブルシューティングは問題が発生したら、それを検知し、どのシステムで何が起こっているかを把握し、根本原因を調査して特定し、暫定的な対応をして、復旧を確認するという流れとなる。

トラブルシューティングの流れ

トラブルシューティングの流れ

検知については準備のところで触れたので、まずは問題の把握から。ここで気をつけることは、焦らずに客観的な目で冷静に把握することだ。原因の特定を急いで、多分これが原因だろうと断定して調べたが実はそこは原因ではなかった、というパターンもよくあるという。

まず考えるのは、いつからどこで問題が発生し、具体的にどのような問題が起きているかを把握することだ。このときのポイントとして、リクエスト数の変化やオートスケールの状況など、ほかに変化がないかもあわせて見ることをTakagi氏は挙げた。

そのほか、ここまでは正常に動いているという境界の部分を確認することも、問題の切り分けのためのポイントとして挙げられた。

トラブルシューティング1:問題を把握する

トラブルシューティング1:問題を把握する

フリーランスのライター&編集者。IT系の書籍編集、雑誌編集、Web媒体記者などを経てフリーに。現在、「クラウドWatch」などのWeb媒体や雑誌などに幅広く執筆している。なお、同姓同名の方も多いのでご注意。

連載バックナンバー

クラウドイベント
第12回

CloudNative Days Tokyo 2023から、クラウドネイティブなトラブルシューティングのノウハウを紹介

2024/4/26
CloudNative Days Tokyo 2023から、メルペイのSRE Tech Leadによるクラウドネイティブ環境におけるトラブルシューティングの手法を解説したセッションを紹介する。
クラウドイベント
第10回

CloudNative Days Tokyo 2023から、Yahoo! JAPANを支えるKaaS運用の安定化やトイル削減の取り組みを紹介

2024/3/11
CloudNative Days Tokyo 2023のセッションから、LINEヤフーの社内KaaSであるZCPを安定運用さるための施策を同社のSREが解説したものを紹介する。

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています