「トラブルは祭り」と思って、進んで参加し成長のチャンスをつかもう
本番の移行作業は、アプリ開発とインフラの2チームが合同で行った。このため移行前の各種検証作業から本番移行まで、各プロセスでスムーズに共同作業を行うための工夫が凝らされた。そうした具体的な例のひとつが、「VMデプロイ パイプライン」だ。これは同社がソース管理に使っているGitLabを介してAWSにモジュールを配信する仕組みだ。これを使うことによって、デプロイ作業が標準化できたと左近充氏は言う。
「当社は開発チームが札幌・東京・福岡の各拠点にあり、これまでは作業手順なども統一されていませんでした。それを『VMデプロイ パイプライン』経由で行うことにより、どの拠点からでも、誰でも確実にデプロイできるようになり、属人化の排除が実現したのです」（左近充氏）
最大の山場である本番移行は、アクセス量がふだんの5分の1程度に減る、5月の大型連休中に行われた。作業を2グループに分け、5連休の初日2日に1日1グループずつ移行を実施。5日目まで挙動を見守り、連休明けから通常の運用に戻すスケジュールだ。
リハーサルを入念に繰り返したかいあって移行作業はスムーズに進み、早くも3日目には全員が「勝利を確信していた」。ところが4日目、突如問題が発生する。データベース（Amazon RDS）のCPU使用率が60％を超えていることがわかったのだ。
「Traceから特定のクエリでCPU使用率が上がっていることをつきとめて、いったんはRDSのスケールアップで13％程度まで抑え込んだのですが、6日目、再び使用率がどんどん上がってユーザーから繋がりづらいという問い合わせを多くいただきました」（左近充氏）
再度詳しく調査を行い、特定の実行プランの異常がCPU使用率の高いクエリの原因であることが判明。いったんは実行プランを過去のものに戻して事なきを得たが、クエリストアを用いての対応だけでは抑えきれなくなる。CPU使用率急上昇の「第2波」がやってきたのだ。
「調べてみると、CPU使用率を上げてしまう特殊なクエリが複数存在していました。ここから社内の有識者の意見も聞きながら、インフラ／アプリ開発チーム全員が『データベース健全化作戦』の約2か月にわたる深夜作業に突入していったのです」（左近充氏）
主な作業としては、（1）統計情報の更新（2）断片化の解消（3）実行プランの固定化が行われた。なお（3）についてはQiita「SQL Server で使用する実行プランを固定化する」に詳しく掲載されている。
昼夜逆転の状態で作業を続けること約2か月、全員の渾身の努力のかいあって作業はみごと完了。CPU使用率も30％程度に抑え込むことができたという。今回の一連の対応を通して得た知識や経験として、左近充氏は以下の3つを挙げる。
（1）データベースは移行前に身を清めておく必要がある
日常的にインデックスの断片化をチェックして、必要なら再構成しておく。
（2）あらゆるパターンのクエリを移行前に試す必要がある
今回は特殊なクエリで発生した障害だが、日頃からあらゆるパターンを試しておく。
（3）他チームとの協働を通じて専門外の知識を学びとる
アプリ開発チームとインフラチームが、互いに足りないことを学び、知識やノウハウを提供し合えた。また長期の共同作業を通じて、お互いに仲良くなれた。
これらの経験とノウハウをもとに、第2弾の移行＝残りのサーバーの移行作業では特に大きな問題もなく、スムーズに完了できたという。
最後にまとめとして左近充氏は、今回の移行プロジェクトでは、まさに今回のデブサミのテーマでもある「ともにつくる」体験ができたと明かし、そうしたマインドを得るために必要な3つのポイントを挙げる。
- 機会は平等ではない＝成長する機会は平等には訪れない。
- 大事なことは積極性＝成長する機会を得るには、やはり積極性が必要。
- 一歩踏み出す勇気＝トラブルが発生していたら、進んで手を貸そう。
自分から進んで機会を見つけていかないと、なかなか成長するのは難しい。左近充氏自身も、トラブルが起きているチームを見つけると積極的に声をかけに行くという。
「トラブル対応は『祭り』だと思って自分から踏み込んでいき、いろいろなチームで貢献すれば、社内でのプレゼンスもおのずと上がっていきます。皆さんもぜひ積極的にトラブルを体験して経験値を増やし、成長につなげていけるよう願っています」と、左近充氏は力強く会場にエールを送り、セッションを終えた。
お問い合わせ
株式会社ブロードリーフ
