こんにちは、遠藤@Cariot事業部です。
今回はCariot SREチームの一員として投稿します。
はじめに
フレクトが提供している車のIoTサービス「Cariot (Car+IoT)」では、先日New Relic社と共同でプレスリリースを発表し、サービスの性能に関する透明性を高めるべく、取り組みをはじめました。
わたしの所属するCariot事業部 製品開発部でも、上記、大きなビジョンの実現を目指しながら、少しずつできることを進めています。
今回は、現在進行中の取り組みについて紹介します。
Cariotのインフラ
もう1年が終わろうとしていますが(早い!)、今年は、大きなサービス障害は起こさずに運用できていたかなと思います。
ただ一方で、サービス品質向上のためには、もう一段レベルを上げる必要があるなと感じた1年でした。 具体的には、自分たちがコントロール可能なインフラだけでなく、連携しているサービス障害に伴い、部分的な機能不全や性能低下が起きたんですね。
- 8月23日に発生したAWS東京リージョンの障害
https://aws.amazon.com/jp/message/56489/ - 9月20日に発生したSalesforceファイルシステム上の障害 https://status.salesforce.com/generalmessages/276
- 11月14日に発生したGoogle Maps APIで500エラーが発生する障害 https://issuetracker.google.com/issues/144461510
みなさんにも心当たりのあるものがあるのではないでしょうか?
また、Cariotというサービスの特徴として、対応デバイスが多種、ということがあります。
シガーソケットに挿すだけのGPSトラッカー、ドライブレコーダー、資産管理用デバイス、スマホアプリ、などです。
これは、利用者のニーズに合わせて最適なものが選べるように、という意図ですが、運用監視の面では、デバイスによって連携システムや通信経路も異なるので、見なければならない範囲が広いということになります。
さて、そういった事情があるにせよ、サービスを使う利用者にとっては、サービスの裏側で何が起きていようと、「今使いたい機能が問題なく動作しているかどうか?」が関心事のすべてであり、連携システムも含めてCariotというサービスの信頼性である、という風に思っています。
(まぁ、もっと言えば、「問題なく動作していることが当たり前」とも言えますが。。)
障害を未来永劫ゼロにすることはできないので、New Relicの導入でさらなる可観測性を高め、顧客の状況に合わせてサービスの健全性を判断した上で、顧客にレポート、アラートするような仕組みの構築をはじめました。
今のお知らせ方法
まずは現状をご紹介。
今のCariotでは、障害をアナウンスする仕組みの概観は次の図のようになっています(一部省略)
まず、サービスの稼働状況を定常的に公開するのに、Atlassian社が提供するStatusPageを使ってます。
公開ページは以下のURLです。
https://cariot.statuspage.io/
ただし、StatusPageだけでは、自発的に利用者がアクセスしない限り、状況を知ることができないので、インシデントが発生した場合は、日常的に利用者がアクセスするアプリケーション上にお知らせが表示されるようになっています。
仕組み的には、お知らせはS3上のファイル(オブジェクト)として存在していて、それをAPI Gateway経由で取得・表示しているという流れです。
また、図には記載していませんが、重大なインシデントの場合は、Pardotを使ってメール配信も行っています。
AWSで取得できるものはCloudWatch、APMレベルで判断するしかない指標についてはNew Relicを使い、Slackのオペレーション用channelにアラートが上がるようになっているので、それを元に障害のレベルを判断し、対応していきます。
定常的なステータスページと、何かあった時に速やかに伝えるためのお知らせやメール配信という2つの軸で、システムの健全性をレポートしているわけですね。
課題と今後の取り組み
上記の仕組みでそれなりに運用はできているのですが、課題はけっこうあります。
- お知らせファイルの更新、ステータスページの更新、部内メンバーへの周知を別々に手動で実施する必要があり、初動に時間がかかる。
- 画一的な方法でしか内容を伝えられないので、利用者の利用形態に合わせた形で伝えることができない。
- SREチーム内で合意済みのSLI/SLOについては判断ができるが、初めて起きた種類のインシデントに対する見極めが属人的
なんとかしたいなと思っていたそんな折、よさそうなAWSのサービスがアナウンスされました。Amazon EventBridgeというヤツです。
ざっくり言うと、SaaSアプリケーションやAWSからのイベントデータを安全かつ簡単に接続してくれるサービスっぽいですね。
で、認証やリトライなどの面倒な部分は面倒を見てくれると。
Auth0との統合の話は一つ前のエントリで齋藤氏が書いてくれています。
ルールでフィルタしたり、ややこしいビジネスロジックはLambdaで扱えそうだし、New RelicとCloudWatchからのアラームの処理を同じ仕組みで扱えそうなので、保守の手間も減らせそうだし、色々とメリットがありそうです。
どうやらNew Relicもサポートされていそうです。
https://aws.amazon.com/jp/eventbridge/integrations/
東京リージョンでも使えるので、早速試してみましょう。
EventBridgeのメニューから「ルールを作成」を選んで、ルールの作成を行っていきます。
このパターンの定義が、イベントソースとかを指定するところなようです。
サービスを選択するところで、New Relicを選べばよさそうですね。
………むぅ、New Relicがない。
もしかすると、New Relicがサポートされたのが最近で、まだ利用できないのかもしれません。
とは言え、近いうちに利用できるようになるでしょう(きっと)
時間がなくなってしまいましたので、今回はここまで。
あんまりテクニカルな内容ではなくなってしまいましたが、Cariotの現状と今考えている取り組みの紹介でした。
形になったらまた紹介できればと思います(近いうちに…)。
それでは。