Google Cloud Platform

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

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

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

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

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

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

エラー トラッキング サービスの Sentry にいつ大量のトラフィックが流れ込むのかは予想がつきません。ユーザーによるイベントが次にいつ起こるかを予測する方法がないからです。そのため、ベアメタルを使っていたときは、スパイク発生時の最悪の状況に備えて過剰にプロビジョニングしていました。

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

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

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

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

私たちは今年 4 月、GCP への移行は可能だと判断し、運用チームはその実現のために 2 か月間精力的に働きました。

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

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

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

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

いわゆる “リフト&シフト” と、クラウドに合わせたアーキテクチャの再構築とを比較し、それらの利点と欠点を十分議論したうえで、私たちは前者を選びました。すばやく移行することを重視し、GCP をハードウェア プロバイダーとして扱うことにしたのです。Google にお金を払うと、GCP が接続先のマシンとコンフィグレーションを与えてくれるという関係です。結果として、私たちの移行プランは、クラウド ベースのアーキテクチャの採用ではなく、従来のプロバイダーから離れることに重点を置いたものになりました。

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

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

正しく橋を架けるということで意見が一致すると、できるだけ安全にトラフィックを切り替える方法を探しました。そして、時間をかけて徹底的にテストしたうえで、自信を持ってすばやく移行したのです。L4 トラフィックの GCP への切り替えは 1 週間で一気に終わらせました。データを処理するプロバイダーと、データを格納するプロバイダーを使い分ける自信がついたのは、この作業のおかげです。

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

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

あの 7 月の霧の深い日が、GCP への移行が完了する運命の日でした。それから数日後、私たちはブックマークから元のプロバイダーのダッシュボードを取り除き、その頃から GCP での運用に慣れていきました。写真を壁にかけ、移行のために入れた shim を取り除き、道の反対側のバーのサービスタイムをチェックしました。しかしもっと重要なのは、リソースの要件がはっきりとわかったので、インスタンス サイズを調整できるようになったことでした。

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

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

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

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

- By James Cunningham, Operations Engineer, Sentry