Cloud SQL で学生、大学、雇用主をつなげる

※この投稿は米国時間 2020 年 12 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: 本日は、就職支援プラットフォームを運営する革新的なスタートアップ企業、Handshake にお話を伺います。同社は、大学や企業などの雇用主と提携関係を結び、大学生が有意義な就職機会を平等に得られるようにするサービスを展開しています。同社のサービスを利用している学生は 700 万人以上、大学は 1,000 校、雇用主は 50 万組織にのぼり、今や米国の初期キャリア コミュニティをリードする存在となっています。この投稿では、Handshake が Google Cloud SQL に移行した経緯をご紹介します。

Handshake は、全国の学生および雇用主を対象にサービスを提供しています。これらのユーザーが必要に応じていつでも Handshake プラットフォームにアクセスできるようにするため、当社では信頼性と柔軟性の両方に優れたテクノロジー インフラストラクチャを必要としています。2020 年には、新しいオンライン ソリューションの提供を開始し、コミュニティ カレッジや教育訓練施設との提携関係のもと学生の就職機会をさらに促進するなど、オンライン サービスをいっそう拡充しました。

こうした変革とそれに伴う成長は、私たちが以前使用していたクラウド サービス プラットフォームの Heroku では、実現が難しかったでしょう。当社のウェブサイト アプリケーションは Rails 上で動作し、クラスタのサイズは大きく、プライマリ データストアとして PostgreSQL を使用しています。しかし、当社の規模拡大に伴い、Heroku のコストが次第に高くつくようになりました。

こうした状況を受け、当社は 2018 年に Google Cloud に移行し、データ管理ツールを Google Cloud SQL に切り替えました。移行の目的は、メンテナンス費の削減はもとより、信頼性の強化や、社内チームに柔軟性および十分なリソースを提供することです。

Cloud SQL によって節約された時間とリソースを、新しいソリューションに投入

この移行は正しい決断だったことが、後に明らかになりました。6 か月かけて比較的スムーズに移行を完了し、今では Heroku に残っているデータベースは一切ありません。現在、私たちのビジネスの中核には Cloud SQL があり、ほぼあらゆるケースで Cloud SQL に依存しています。クラスタのサイズは依然として大きく、PostgreSQL を単一の信頼できるデータ源および情報源として使用しています。PostgreSQL には、学生や、雇用主、大学の情報など、ほぼすべてのデータが格納されています。当社のウェブサイトに含まれる要素はすべて、なんらかのデータモデルへと変換されてからデータベースに反映されます。

当社の主要なウェブ アプリケーションでは、モノリシックなデータベース アーキテクチャを使用しています。インスタンスはプライマリとリードレプリカが 1 つずつ、CPU は 60 個、メモリは約 400 GB、ストレージは 2 TB で、そのうち 80% を使用しています。

Handshake では、複数のチームがデータベースを使用しています。たとえば、インフラストラクチャ チームやデータチームのほか、学生、教育機関、雇用主など、それぞれの担当チームがあります。データチームは通常、トランザクション データを操作して、パイプラインを記述したり、データを PostgreSQL から抽出して BigQuery や Snowflake に読み込んだりします。当社ではすべてのデータベースで独立したレプリカを実行しており、データチームはこれらのレプリカを使うことで、パフォーマンス上の影響を受けることなくデータをエクスポートできます。

マネージド サービスにおいては、メンテナンスやそれに伴うダウンタイムがあるのが常ですが、Cloud SQL はこうしたメンテナンスを簡単にスケジュールできます。もしもデータチームのほうで、メモリや、性能、ディスク容量を拡張する必要が生じた場合は、インフラストラクチャ チームが調整を担当し、メンテナンスの時間枠やそれに類するダウンタイム ゼロのアプローチが必要かどうかを判断するという流れになっています。

さらに、当社ではキャッシュに Memorystore を使用し、Elasticsearch を多用しています。Elasticsearch のインデックス システムでは、バッチ処理用の独立した PostgreSQL インスタンスを使用します。主要なアプリケーションでレコードが変更されると、Pub/Sub メッセージが送信され、インデクサがそのメッセージをキューから受信します。続けて、インデクサは該当するデータベースを使って、Elasticsearch への情報格納やインデックス作成などの処理を行うという仕組みになっています。

機敏性、柔軟性、今後の計画

Cloud SQL でデータベースを管理するようになってから、空いたリソースを新しいサービスやソリューションの開発に回せるようになりました。仮に PostgreSQL クラスタを自分たちで実行していたなら、データベース管理者を雇わざるを得なかったでしょう。もしもサービスレベル契約（SLA）の保証がされている Cloud SQL のようなサービスがなく、Compute Engine 仮想マシン上に自分たちで PostgreSQL インスタンスをセットアップしなければいけなかったら、Google Cloud と同じだけのことをするために社内チームの要員を倍増しなければならなかったと思います。Cloud SQL には、自動プロビジョニングや、ストレージ容量管理などの機能もあるので、貴重な時間をさらに節約できます。

当社で行う処理は通常、書き込みではなく読み取りが中心なので、今後の計画としては、リードレプリカにオフロードする読み取りをもっと増やして、プライマリを書き込み専用にし、PgBouncer を使ってクエリの送信先データベースを自動判断する仕組みを確立したいと考えています。

また、基本的な Cloud SQL 使用の大半をカバーしてくれる確約利用割引の使用も検討しています。一方で、コスト節約を柔軟に行う手段を維持しながら無駄な利用を省き、最初から一定の節約効果を得たいと考えています。さらに、現在のモノリシックなデータベースを小さいデータベースに分割し、影響範囲を狭めることで、目的ごとに効率良く調整を行えるようにしたいとも考えています。

Handshake では、Cloud SQL および関連サービスのお陰で解放された時間とリソースを有効活用し、今後も引き続き、学生や、大学、雇用主の変わりゆくニーズに柔軟に応えていく所存です。

Handshake の詳細や、Cloud SQL に含まれるソリューションについてもお読みください。

-インフラストラクチャ エンジニア Chris Lau

-インフラストラクチャ エンジニア Rodney Perez