Diary of a Perpetual Student

Perpetual Student: A person who remains at university far beyond the normal period

Mackerel AzureインテグレーションSDK移行の裏側

arthur-1 Mackerel Advent Calendar 2023ラソン15日目の記事です。(12/15に投稿予定でしたが都合がつかず本日12/17の投稿となります。)

Azure SDKライブラリの更新が必要になった

MackerelはAzureインテグレーションという機能を提供しています。我々が運用するクローラーで定期的にAzureのAPIにアクセスし、そこから得たリソースやモニタリング情報をMackerel上のホストやメトリックとして投稿するサービスです。この機能によって、mackerel-agentを導入できないようなフルマネージドのPaaSなどもMackerel上で監視することができます。

このクローラーはその役割として求められる性質から、非同期処理をスマートに扱えるGo言語で作られており、Azureが提供するGo言語向けのライブラリを利用しておりました。しかし、使っていたライブラリが2023年9月にサポート終了となることが発表されました。

azure.microsoft.com

Mackerel開発チームでは株式会社アイレット様のご協力をいただきながら、利用しているライブラリを新しいものに置き換えることにしました。

cloudpack.jp

今回は、サービスを無停止のままSDK移行を完了したその裏側について、具体的なモニタリング手法に着目してご紹介します。

SDK移行の進め方

Azureクローラーが行う処理のうち、SDKを置き換えることで書き換えなければいけないものは主に以下の3つです:

  • 認証
  • リソースの取得(サービスごと別個の処理)
  • リソースのメトリックの取得(サービスに関わらず共通)

このうち、認証とメトリックの取得に関してはAzureのサービスに依らず共通のため、まずこちらの部分を新しいSDKを用いた実装に切り替えることにしました。それが完了してから、Azureのサービスごと実装しているリソースの取得部分について、1サービスずつ新しい実装に置き換えていくことにしました。

リリースフラグの導入

きちんと動作テストを行なってからリリースに臨むものの、ライブラリを乗り換えることでバグが埋め込まれてしまう可能性があります。また、リリース後すぐにバグに気づければ直ちにロールバックすれば良いのですが、特定の条件でのみ発生する場合にはリリース後すぐに気付けない場合があります。気づいた頃にはすでに他のサービスの実装についても改修が進んでいるため単純なロールバックは難しく、またrevertするには時間が掛かるということもあるでしょう。

そこで、サービスごとのリリースフラグを導入することにしました。サービスごとに旧実装を用いるか新実装を用いるかを切り替えられる制御盤を作り、この制御盤が更新されたらSlackに通知するようにしました。

不具合が起きてもフラグ更新通知の時刻を遡ることで、SDK移行のリリースが原因であることが分かりやすくなります。また、不具合が起きた時に分かりやすいGUIでフラグを変更することですぐに特定のサービスだけ実装を巻き戻すことができます。

さらに、単なるON/OFFだけでなく、オーガニゼーションの範囲を絞ってリリースすることもできるようにしました。本番環境で仮リリースして社内のAzureのリソースで様子を見てからユーザー全体に向けてリリースすることが可能になりました。

サービスごと影響を確認できるダッシュボードを作成

従来からサービスメトリックとして、Azureのサービスごとのクローラーに関する様々なメトリックを投稿してグラフとしてダッシュボードに表示していました。

画像はイメージです

しかし、今回のSDK移行ではサービスごと作業を進めていく関係で、特定のサービスにのみ着目したいことがありました。たとえば、グラフに全ての系列が表示されていると、大きい数量のメトリックのせいで本来見たいサービスの微小な変化に気付けないことがあるでしょう。そこで、以下のようにサービスを1つ絞って見たいメトリックが見れるようなダッシュボードを作りました。

サービスごと同じようにグラフがダッシュボードに並ぶ(メトリックのキーだけが異なる)という性質から、Terraform Provider Mackerelを活用して機械的に作って行きました。以下の記事でdynamic blockを活用してウィジェットを複製する手法を紹介しています。

blog.arthur1.dev

ログやトレースも充実させる

SDK移行に伴う書き換えの影響で、一部の処理が遅く満足にjobを捌けなくなるなどの問題も起こっていました。そこで、SDK移行作業をトラブルなく完遂するだけでなく今後も詳細な調査に役立つだろうということで、ログやトレースを充実させていきました。大きな変化やアラートはメトリックで気付き、その後の調査にはログやトレースを用いるという役割分担です。


いかがでしたか?こういった事例を詳細に表に出す機会があまりないので、今回ご紹介させていただきました。Mackerel開発チームではMackerelの信頼性を落とさずに機能開発や保守を行うための工夫を凝らしており、またそういった工夫がMackerelに新機能を追加するアイデアが生まれるきっかけになっています。