事例 : ベアメタルから GCP への移行で Sentry が学んだこと

編集部注 : Google Cloud Platform（GCP）への移行は刺激的であると同時に骨の折れる作業かもしれませんが、そう感じるのはあなただけではありません。Sentry は今夏、数か月かけてプランを立てたうえで、エラー トラッキングのオープンソース ホステッド サービスを、思い切ってベアメタル プロバイダーから GCP に移行しました。この投稿では、同社がなぜ移行を決意したのか、どのようにしてプランを立てていったのかを紹介します。

それは 7 月最初の週末のことでした。私たち Sentry の本社は米国サンフランシスコにあるのですが、こんなことなら物体 X を避けるために南極の研究所で “ハドル”（円陣）を組んだほうがよかったのではないかというくらい、霧と風がひどい日でした。

その日、Sentry の運用チームは SoMa（South of Market : マーケット通り南）の本社に集結し、インフラストラクチャの GCP への移行を完了させました。それまでの 2 か月半、私たちは休みなしで作業を行い、その日は sentry.io の DNS レコードを切り替え、トラフィックが少しずつテキサスのコロケーション プロバイダーからアイオワの us-central1 に移っていくのを見ていました。

専用のハードウェアを手放してから数か月が経ちましたが、まだダウンタイムは発生しておらず、ベアメタルからクラウド プロバイダーに切り替えたことにとても満足しています。この投稿では、今回の移行から学んだことを紹介します。

目的は予想外の需要に応えること

もっとも、そうしていたのは私たちだけではありません。専用ハードウェアで運用する場合、これは一般的な方法です。また、プロバイダーは価格競争に走りがちなので、私たちのようなユーザーはコンピューティング パワーのメリットを安価に享受していました。

そうこうするうちに、需要の拡大に歩調を合わせる形で、新しいマシンを調達するまでの期間が徐々に短くなっていきました。私たちは、本当に必要になる前にマシンを導入して何日も遊ばせており、必要以上のものを抱えていました。特注のマシンを必要とするようになると、データベースとファイアウォールの連結に要する時間がコモディティ ボックスのときよりもさらに長くなり、この問題は悪化しました。

最も良い条件下でも、まるで Marshawn Lynch（NFL の選手）がフットボールを抱えて走るように、マシンを抱えてフロアを全速力で走るオンサイト エンジニアを配置しなければならず、神経がすり減って大変でした。そうしたことから、GCP に切り替えることを決めたのです。GCP ならマシンはすでに用意され、要求してから数秒後には立ち上がり、そのうえ支払いは使った分だけに抑えられます。

橋を架けるのは渡るよりも難しい

移行するにあたって最も優先したことは、データセンターが 1 つだという前提に基づく部分をすべて取り除くことでした。Sentry はもともと部屋と部屋の間で通信する内部サービスとして作られています。移行中はその距離が数百マイルに延びるため、予想外の形で動作が変わる可能性があります。同時に、移行中に 2 つのプロバイダーを併用したとしても、それまで 1 つのプロバイダーで維持できていたスループットを確保したいと考えていました。

私たちを悩ませた最初の分岐点は、ネットワーク ブリッジでした。選択肢は、従来の IPsec VPN を維持するか、プロバイダー間の任意の接続を暗号化するかの 2 つでした。両者を比較検討した結果、パブリック ネットワークのエンド ツー エンドにおけるレイテンシは十分低く、非公開データを stunnel で保護すればパブリック ネットワークでも可能ということになりました。疑似 NAT として機能するマシンを介したプライベート トラフィックのファネリングが、驚くほどの高成績だったのです。およそ 650 マイル離れた 2 つのプロバイダーの間でも、確立された接続のレイテンシは 15 ミリ秒前後でした。

私たちはそれ以外の時間を最悪のシナリオのシミュレーションに費やしました。「特定のマシンがいなくなったらどうなるか」、「どこかで問題が起きたときにトラフィックを逆方向に切り替えるにはどうすればよいか」といったことです。障害シナリオを数日間検討した結果、私たちは最終的に GCP に移行できるという結論に達しました。ただし、2 つのプロバイダーの間でのやり取りに時間がかかればかかるほど回復力が制限されるという条件付きでした。

インフラに変更を加えるたびに予定が長引く

もちろん、移行するにあたって GCP サービスの採用についても議論をしました。しかし、そのことは脇に置き、移行の主な理由はアーキテクチャではなくインフラストラクチャだということを思い出すようにしました。インフラストラクチャの変更を最小限に抑えれば、必要な作業が減るだけでなく、アプリケーションの動作が変わる可能性も低くなります。私たちの課題は橋を架けることであって、Sentry を作り直すことではありませんでした。

盗塁のようなスピードで移行する

そこから本格的に移行を開始しました。最初はアクセスの多いデータベースのフェイルオーバーでしたが、それは Google Compute Engine が本当に私たちの I/O についてこられることを再確認するためでした。この条件が確認されると、あとはほかのすべてをどんどん GCP に移していきました。その他のデータベース、書き込みをするワーカ、読み出しをするウェブ マシンなどです。私たちはできることを躊躇なく行いました。盗塁と同じで、慎重なプランニングと果断な実行が移行を成功に導いたのだと思います。

掃除しなければほこりは落ちない

とはいえ、Compute Engine で必要となるリソースの予測にどれだけ時間をかけたとしても、スループットの向上は予測できません。GCP のデフォルト マイクロアーキテクチャである Haswell のおかげで、CPU 集約的なワークロード、すなわちソース マップ プロセッシングのパフォーマンスが向上したことはすぐに気づきました。それからの数週間、運用チームはインフラストラクチャを非常に抑制的に縮小していきましたが、それでもインフラストラクチャのコストは約 20 % も削減しました。しゃれたクラウド テクノロジーや大規模なインフラストラクチャに取り組んだわけではありません。今までよりも数学が得意なハードを入れただけです。

同一条件での移行が完了したので、Sentry をさらに打たれ強いサービスに鍛えるのに役立つ GCP の機能を調査することになりました。今後の投稿記事では、そうした機能とコスト削減のために使ったテクニックを紹介する予定です。

最後に、このプロジェクトで活躍してくれた Matt Robenolt と Evan Ralston に感謝の言葉を贈りたいと思います。2 人は Sentry チームにとってかけがえのない存在です。私たちは、次のインフラストラクチャの構築に力を貸してくれる新しいチーム メンバーを迎え入れるつもりです。あなたも手を挙げてみてはいかがでしょうか。

* この投稿は米国時間 10 月 19 日、Sentry の Operations Engineer である James Cunningham 氏によって投稿されたもの（投稿はこちら）の抄訳です。

- By James Cunningham, Operations Engineer, Sentry