はてな粕谷氏が実践する「プロダクトを10年運用するチームの作り方」：「Developers Summit 2020」レポート（2/2 ページ）

[編集部,＠IT]

2019年夏のAWS障害も「予習済み」だった

　障害対応はさまざまなスキルが必要な難易度の高いタスクだ。システムそのものの理解はもちろん、ソフトウェアやミドルウェア、OSなどさまざまな知識が必要となる。粕谷氏によると障害対応で問題なのは「実際に障害対応をした人にナレッジが集中する」属人化にあるという。

　「新しいメンバーがチームに入ったからといって、障害発生時に『ではペアプログラミングで対応しようか』というわけにはいかない」（粕谷氏）

　新しいメンバーは障害が発生しても、何が起こっているのか分からないし、何をすればいいのか、何を勉強すればいいのか何も分からない状態だ。障害対応が最優先なので過去に対応実績のある人が対応することになるがそれではいつまでたっても属人化した状態から抜け出せなくなる。

　これに対し、Mackerelが実践しているのが障害対応演習、つまり避難訓練だ。半期に1回ほどの頻度でスキルマップを参考に担当者をアサイン。ステージング（待機系）環境をわざと壊して復旧させるといったものだ。実際の障害が発生した直後に同じシナリオで実施することが多く、当日障害対応に参加できなかった人を中心に対応することが重要だという。実際の障害を参考にすることで振り返りの効果があるし、今後同様の障害が発生した場合にベテラン以外のメンバーでも慌てず、迅速に対応できるようになる。

障害対応演習（出典：はてな）

　Mackerelが実際に演習したシナリオには「マルチAZ構成にしているAWS（Amazon Web Services）のAZ（アベイラビリティーゾーン）の一つを意図的に壊して復旧させる」「データベースを意図的に壊して復旧する」などがある。AWS障害シナリオは、偶然にも2019年に発生したAWS障害の1週間前に演習していた。そのため実際の障害時に「これ、演習でやったやつだ」と落ち着いて対処でき、1時間程度で復旧ができたという。

　演習は思い付きで実施することもある。粕谷氏が有給で休んでいる日にSlackでデータストレージ破損の連絡があり、急いで帰宅したところ、メンバーから「すみません、これ演習です」と伝えられたことがあるという。「思いがけず緊急時のディレクターの負荷試験になった（笑）。事前に言ってくれればとは思ったが、思い付きでやることで新たな発見があり、面白いかもしれない」（粕谷氏）。

技術的負債とシステムのスケール

　粕谷氏は最後に「技術的負債とシステムのスケール」として、長期間プロダクトの運用を続けることによって変わるものとして、システムのスケール（成長）を挙げた。Mackerelでいえば2015年（FY15）から2019年（FY19）までで累積顧客指数がおよそ40倍になったという。これほどサービスが成長するとアクセス数は急増し、システムに掛かる負荷も増える。それに伴ってシステム基盤に求められる要件も変化すると粕谷氏は語る。

　「サービスを開始した当初はオンプレミス環境でモノリシックに作る、といったことが一般的だった。現在はコンテナでマイクロサービス化することが主流になってきている。そして最初から大きな規模で始めるのではなく、小さく作ってから育てる必要がある。従来も将来の規模感を予測してスケーラブル（拡張できる）な設計はしているが、周辺環境の変化や予想を超えるスピードでサービスの規模が拡大することがある」

　Mackerelもオンプレミス環境にモノリシックなシステムで構築されていたが、新たな機能開発をきっかけにマイクロサービス化を少しずつ進めていった。オンプレミスからクラウドにシフトが完了し、サブシステムを順次コンテナ化しているさなかだという。

　粕谷氏は10年単位で長い間運用していると、サービス成長に合わせてシステムをスケールしたり、当初はビジネスを優先して後回しにしていた技術的負債を解消したりするために一定のタイミングでシステムの根本に手を入れる必要がある、と説明する。粕谷氏はこれを「ソフトウェアの式年遷宮」と呼んでいる。

式年遷宮で新しい世代に技術が継承される

　式年遷宮とは、20年に一度社殿を建て替えることで、宮大工の技術継承や社殿の姿を維持する目的があるともされる。隣に全く同じものを建てることで、単純な改装と違い、社殿の姿をほぼそのまま維持できるのがメリットだ。ITの現場でも長い期間運用されているシステムにおいては、こうした仕組みが必要だと粕谷氏は説明する。

　「現実の式年遷宮は宮大工の技術を継承し、姿を維持することが目的だが、ソフトウェアの場合はアーキテクチャやフレームワークなどシステムの根幹部分に手を入れて、新しいモダンな形に作り替えることが目的だ。そうすることでシステムのスケールに対応できるし、技術的負債も返済できる。エンジニアの技術習得にも役立つ」（粕谷氏）

ソフトウェアの式年遷宮（出典：はてな）

　式年遷宮をする前はシステムを構築したメンバーが最もプロダクトに詳しいが、式年遷宮をすれば、式年遷宮に参画したメンバーが最も詳しい人になる。このように世代交代がスムーズにできる点もメリットだという。

　実際にMackerelは式年遷宮によってシステムの根幹に関わる変更を幾つも実施しているという。例えばオンプレミスからクラウド環境への移行、時系列データベースをオープンソースソフトウェア（OSS）の「Graphite」から自社開発した「diamond」に変更するなど。現在は、フロントエンドをAngularJSからReactに移行中だという。

　「そもそもの話として、10年稼働し続けているシステムがあったとして、そのシステムのアーキテクチャは10年前のものだ。それは現在も有効か、というと疑問がある。ソフトウェアを使ってサービスを提供している以上は、新しい技術に移し替えることで運用も楽になるし、ソフトウェアそのものの価値も上がっていくだろう」（粕谷氏）

　粕谷氏は最後に、プロダクトを10年運用するチームを作るためのポイントをまとめた。

　「システムの周辺環境は日々変化する。OSやミドルウェアはどんどんアップデートされるし、ビジネスも変化する。システムはそれに合わせて変化するために、まずはシステムの基盤を整えましょう。10年運用を続けるためには、人が入れ替わったときにどうするかをしっかり考え、対処しましょう。システムのスケールを考えた定期的な対処をしていきましょう。こうした取り組みをすることによって10年20年、恒久的にシステムを維持できるだろう」