アーキテクチャレビューはじめました

Published in

FiNC Tech Blog

10 min readJun 22, 2020

FiNCの篠塚(@shinofumijp)です。4月からCTOを拝任しました。
本記事では1月から行ってきた「アーキテクチャレビュー」という取り組みについて紹介します。

FiNCではマイクロサービスを6年前から採用しており、順調にサービスも成長したおかげで、現在では稼働しているマイクロサービス数は50を超えるほどになりました。
マイクロサービスの採用により、限られた範囲での開発においては速度を落とさずスケールすることが可能という恩恵を得られましたが、一方でサービス数の増加は安定性、メンテナンス性をはじめとした様々な問題も生みました。その1つにアーキテクチャ全容の理解が困難になるという問題があります。例えば「ユーザが食事を投稿した際に食事アドバイスのプッシュ通知を送る」という機能1つをとっても、アドバイス管理サービスが食事投稿のイベントを検知するためにイベントを購読し、同サービスがアカウント管理サービスやユーザのライフログデータを管理するサービスなどからユーザデータを集め、そして非同期のジョブキューに通知サービスのAPIを利用するジョブを積みワーカーが実行する、といった構成で実現しています。

こういった複雑さは特にSREのようにマイクロサービスエコシステム全体を支えるチームとしては日々の業務に支障を与えるほどになりました。

加えて、スタートアップ企業の開発には往々にしてあることですが、標準化の仕組みが追いつく前に新規開発を急いだり、サービスを運用する中でエンジニアの入れ替わりもあったため、理解している人がほとんどいないアプリケーションも生まれてしまいました。

開発に関わっていないアプリケーションでは具体的には以下のものが不明となっていました。

アプリケーションの責務
他のアプリケーションとの関係性
アプリケーションの影響範囲、依存先と依存元
アプリケーションに求められる安定性やレイテンシ、スループット等のパフォーマンス要件

これらが原因となって、開発速度の低下、予期しない障害を生んでしまう、障害時の対応が長引く、といったことが起きていました。

プロダクションレディマイクロサービスとの出会い

このような状況下でFiNCのアプリケーションアーキテクチャの理解を深め、より安定してスケール可能なアーキテクチャを検討することを目的として「アーキテクチャレビュー」を行うことにしました。
アーキテクチャレビューのアイディアはプロダクションレディマイクロサービスより拝借しました。同著にはUberのSREエンジニアがマイクロサービスを高い水準で標準化するために社内で行ったことがまとめてあります。

アーキテクチャレビューの進め方を参考にしたのはもちろん、FiNCには元々「プロダクションレディ(= アプリケーションがプロダクション環境で稼働するために満たすべき要件)」という概念がなかったことの気づきや、マイクロサービスにおけるアプリケーションエンジニアとSREの役割を見直す機会にもなりました。
元々FiNCではアプリケーション運用、特にインフラ要件周りはSREが担当しており、いわゆるDevとOpsが分かれている状態でした。しかし、日々開発の進むアプリケーションに対してSREだけでプロダクションレディへの対応を行うのは不可能なため、アプリケーションエンジニアにもマイクロサービスエコシステムを理解し、プロダクションレディへの対応まで担ってもらえるように、サービス開発の心得の啓蒙や権限移譲をはじめとした開発体制の変更も行いました。

アーキテクチャレビューの進め方

準備

サービスの選定
全部で50を超えるマイクロサービスがあり、時間の制約上全部のサービスをレビューするわけにもいかないため、レビュー対象とするサービスを選定しました。

選定の基準として課金機能を有している、リクエスト数が多いものなど、ビジネスに影響を大きく与えるものを中心に30個程度に絞りました。

テンプレートの準備
アーキテクチャレビューはアプリケーションのドメイン知識を有している、担当のアプリケーションエンジニアを中心に行います。アプリケーションエンジニアの準備の手間を削減するためにテンプレートを用意し、あわせて事前準備する項目とレビューを通して確認する項目を分けるようにしました。

事前準備が必要な項目

アプリケーションの責務
主に何をやるサービスか、何はやらないか、類似サービスがあればその境界など
APM(Application Performance Manager)のURL
依存関係の図
Datadog(後述)のServicesをキャプチャして利用
パフォーマンスとスケーラビリティのボトルネック
思い当たる場合は記載
単一障害点
思い当たる場合は記載
起こりうるインシデントや機能停止
思い当たる場合は記載
主要メトリック
決まっている場合は記載、決まっていない場合はアーキテクチャレビューを通して決定
プロダクションレディチェック
プロダクションレディマイクロサービスに記載されているチェック項目をFiNCの基準でレベル分けして、満たせているものと満たせていないものを確認した。あらゆるアプリケーションが満たすべきレベルには包括的なドキュメントの用意や、デプロイパイプラインの整備と自動化など。努力目標のレベルには障害の自動的な検出と復旧や、単一障害点の排除などを分類した。

アーキテクチャレビューを通して確認する項目

アーキテクチャ図
トラフィックのパターン
プロダクションレディへのロードマップ

実施内容

参加者にはサービスを担当するエンジニアとSREの出席は必須とし、その他のエンジニア、企画職の人に対してもオープンにして実施しました(本筋とは逸れますが大人数のスケジュールを押さえるのでスケジュールの調整が地味に大変でした・・・)。

アーキテクチャレビューはテンプレートに沿って進めます。まずアプリケーションの責務を確認した後に、主要な使われ方の処理の流れをホワイトボードを用いて説明します。FiNCではDatadogという監視サービスを用いており、サービスの依存関係を表示する機能もあるので併せて利用しました。ただ、ユーザのサービス利用とどのように関係しているかといったドメイン知識と結びつけた情報や、処理の流れといった動的な情報はトラッキングされた情報からはわからないため、ホワイトボードでアーキテクチャを図示しながら解説しました。

次に、処理の流れの中で、依存先がダウンしていた場に何が起きるのかを確認します。例えば、データの不整合が発生するか、リトライすることで結果整合は保たれているか、自身を呼び出すサービスが連鎖してダウンすることはないか、などを確認しました。特に、ログイン情報を管理するサービスや、ユーザ名などの個人情報を管理するサービスへの依存が多くなってしまうので、これらのサービスを利用している場合にはリクエストがスパイクする可能性、ダウンすることで起き得る二次災害や大惨事、回避する方法の検討を慎重に行いました。

続いて現状のメトリックを確認します。エラーレート・負荷に異常なスパイクが発生していないか、日次や週次や月次で負荷が上がることはないか、ある場合は依存関係含めたオートスケールは適切に設定されているか、などを確認しました。また、アプリケーション全体の中でのサービスの果たす役割を考えた上での注視すべきメトリックを確認しました。非同期ジョブが中心のサービスであればワーカーのスループットと個々のジョブの完了時間、ユーザのアカウント作成後のチュートリアルを担当するサービスであれば完了率や完了にかかるまでの時間など、インフラレベルのものとサービスレベルのものをそれぞれ確認しました。

最後にラップアップとして上がった問題を優先度付けして、プロダクションレディにするためのTODOとロードマップを作成しました。具体的に出てきたTODOの例としては、監視できていない主要メトリックの取得、ダッシュボードの作成、APIのタイムアウト時間の見直し、依存先がダウンしている場合に遅延実行を行う仕組みの実装、キャッシュの利用、効率の良いルーティングの利用などが出ました。

実施後

アーキテクチャレビューで出てきたTODOは緊急のものはすぐに対応し、それ以外のものはチケット化して開発スケジュールに入れて対応しました。またFiNCには月に1日、新規開発を止めてメンテナンス及び負債解消を行う日があるのでその日も使って対応をしました。

アーキテクチャレビューを複数のサービスを対象に行ったことによって共通した課題も発見することができたので、サービス毎に解決するのみでなくライブラリを作ったり、インフラレベルで解決することも行いました。

アーキテクチャレビューを振り返って

アーキテクチャレビューの質は参加者に大きく依存します。例えば、アプリケーションエンジニアがアプリケーション知識を幅広く有し、よく理解している場合には議論も深まりました。分散システムやアプリケーション運用の経験が長いエンジニアがいたおかげで、アプリケーションに応じた起こりうる機能障害のシナリオや有効な回避策の提案もあり、参加者全員の学びにつながることもありました。

得られた恩恵

認識していなかった依存関係、トラフィックパターン、将来起き得る問題の把握や、マイクロサービスエコシステムの中における自サービスを見直すきっかけとなりました。新規実装時のアーキテクチャの相談も共通の前提がある上で行われるようになり、不安定化につながる依存を避ける方法の検討をするなど、分散システムを意識した設計と実装が行えるようになりました。

またアーキテクチャレビューで使用したドキュメントも開発ガイドとして保存したことで、新しく開発に参加したエンジニアのキャッチアップの助けにもつながりました。

今後

アプリケーションアーキテクチャは今後も変更されていきます。また、ユーザ数やユーザの利用方法に応じて、トラフィックのパターンやスケーラビリティの課題も変わってきます。そのためアーキテクチャレビューは定期的に行う予定です。
高い水準で安定したアーキテクチャやアプリケーション運用を行っていくためには多くの課題があります。SLI/SLOの設定と運用、適切なアラートシステムとロギングシステム、単一障害点の排除、自動化された障害検知と回復、などなど。
FiNCではSREと協働してこれらの課題の解決し、ユーザによりよい体験を届けるサーバーエンジニアを募集しています。

https://www.wantedly.com/projects/444990

追記

2020–06–30
本記事で紹介したアーキテクチャレビューの取り組みについて、FiNC主催のオンラインミートアップでより詳細に紹介します。
https://finc.connpass.com/event/180590/