[レポート] SmartHR が少人数で Google Cloud へ（ほぼ）全移行を完了させた方法 ＃GoogleCloudDay

こんにちは。CX事業本部MAD事業部のYui(@MayForBlue)です。

「Google Cloud Day: Digital ’22」が2022年4月19日~21日に開催されました。
本ブログはイベント内のセッション「SmartHR が少人数で Google Cloud へ（ほぼ）全移行を完了させた方法」のレポートブログです。

セッション概要

概要

SmartHR は、今年 1 月にほぼ全てのプロダクトを Google Cloud へマイグレーションしました。 我々が、どのような課題を持っており、どう考え、どこで苦労したか？を交えながら、 如何にして少人数でマイグレーションを実施したかをご紹介させていただきます。

取り上げる主な Google Cloud 製品 / サービス

• App Engine
• Cloud Run
• Cloud SQL

スピーカー

株式会社SmartHR 藤村 宗彦 さま

SmartHR社のサービスについて

• 人事・労務業務の効率化を通じて生産性の向上や働きたい職場環境の創出を目的としたクラウド型ソフトウェア

プロダクトの構成

• Plus のプロダクトについては機能ごとにチームが分かれてそれぞれのプロダクトとして開発している

移行前のアーキテクチャについて

移行前の課題

• Citus Cloud (DBaaS）のサービス終了に伴う対応
• プロダクト横断利用で適切な権限分離ができていなかった
• インフラの構成管理 etc...

移行後のアーキテクチャについて

Google Cloud を採用した理由

• 導入実績の豊富さ
• コンテナ化されたサービスが扱いやすい
• プロダクトの開発や運用支援ツール、APIが十分揃っている
• アカウントの管理・権限が統制しやすい
• ネットワークの柔軟性が高い etc...

主に利用したサービス

• Cloud Run
• App Engine (flexible)
• Cloud SQL for PostgreSQL

Cloud Run を採用した理由

• シンプルな Rails アプリケーションでプロダクトを構成していた
• インフラの運用コストを下げたかった
  • マネージドサービスで統一的な運用ができる
• スパイクアクセスでも十分にスケールできる
• 全てを App Engine に倒す構成も検討していたが、デリバリーフローに懸念があった
• 機能拡充のペースが早く、学習コストが高くない

App Engine を併用している理由

• 移行検討時に Cloud Run の Always on CPU の機能がなく、非同期処理の実行環境として不向きだった
• 長時間の処理やマシンパワーを要する処理には Cloud Run は不向きだった
• ノウハウが多いので移行の不確実性や学習コストの削減を見込めた etc...

GKE を採用しなかった理由

• Google Cloud に対する学習コストに加えて Kubernetes の学習コストがかかることに懸念があった
• 運用面で考えなければならないことが多い
• 構成の統一や人のスケールが難しい
• 移行検討時に GKE Autopilot が存在しなかった etc...

少人数の移行でやったこと

移行までのスケジュール

• 2019年8月に移行検討開始
• 2020年10月に Google Cloud へ移行決定
• 2021年4月〜2022年1月の間にほとんどの機能の移行ができた

対応内容

• 監査対応
  • 監査ログの取得対応
  • ログのエクスポート対応
  • ログモニタリングと検知の対応 etc...
• リソース整備
  • リソース階層や組織ポリシーの決定
  • 課金設定
  • プロダクト個別のプロジェクト作成によるアクセスと権限の分離対応 etc...
• インフラの構成管理対応
  • Terraform による構成管理
  • Terraform Cloud による適用
• CI / CD の整備
  • AWS / Heroku に向けたデプロイから切り替える必要があった
  • CI/CD フローの型を用意し、各プロダクトに展開することで迷うことなく移行対応を実施できた
  • ほとんどのプロダクトでデリバリーフローを統一した

移行作業の内容

• Amazon ElastiCache / Heroku Redis から Memorystore for Redis への移行
  • ElastiCache の rdb ファイルのエクスポート機能を利用してエクスポート
  • Memorystore の rdb ファイルのインポート機能を使って移行
  • Heroku Redis には rdb ファイルのエクスポート機能が存在しなかったので redis-cli をセットアップして対処した
• S3 から Cloud Storage への移行
  • S3 からの転送は全て Transfer Service を利用した
  • 約 1000 万件、12TB 規模のバケットを約2時間で転送
  • S3 Batch Operations と AWS Lambda を使って、転送後のファイルに破損や欠損が内科確認した
  • 転送後の全てのオブジェクトに対して MD5 のチェックを実施した
• Amazon RDS から Cloud SQL への移行
  • Database Migration Service を検討したが、稼働中のRDSに操作が必要だったので見送った
  • シンプルで理解しやすい pg_dump を利用
• Citus Cloud から Cloud SQL への移行
  • Cloud Spanner という案もあったが、設計やデータ変更の必要がありそうだったので不採用
  • シャーディングがない PostgreSQL でも動かせるとわかっていたので Cloud SQL を利用
  • テナントレベルのデータ分離はアプリ層に「activerecord-multi-tenant」を採用することで対処した

運用のナレッジ

• Cloud Run で Rails アプリを稼働させるポイント
  • 高負荷によるコールドスタートを避けるため最小台数に余裕を持たせる
  • スケールアウトを見越して最小台数と最大台数に幅を持たせる
• Oparations suite の活用
  • Cloud Monitoring
  • Cloud Logging

少人数移行でのまとめ

• プロダクト/セキュリティチームと連携してチーム体制を整えることで機能開発を止めることなく移行ができた
• インフラの構成管理とプロダクトの実行環境の統一ができた

今後の展望

• データを活用しやすいように分析基盤の再構築
• プロダクトのさらなる安定稼働のためのQA環境構築
• PostgreSQL の Row Level Security の導入
• コンテナ環境のさらなる改善 etc...

Q&A （抜粋）

Q. 移行によって運用のしやすさがどのように改善されたか
A. 全プロダクトで同じ構成を取るようにしたのでノウハウが水平展開できるようになった。
ログを Cloud Logging に集約できて横断的に見られるようになった。

Q. 移行について Google Cloud を選択した一番の決め手は？
A. セッション内で紹介した点に加えて、アカウント管理に Google Workspace を使っていたのでアカウント管理も含めて運用しやすい点や、Looker / BigQuery と統合しやすい点が決め手となった。

Q. 今後の展望におけるコンテナ環境のさらなる改善についてどんなことを考えているか
A. Cloud Run の改善スピードが早いので状況に応じて追従していきたい。デプロイ周りなども含めて包括的に改善していきたい。

感想

クラウド間の移行という貴重な実体験の中で、少人数体制でもしっかり準備をされて移行を成功されたノウハウが興味深かったです。 また、アーキテクチャの選定理由についてポイントがしっかりおさえられており、各サービスの特徴やメリット・デメリットが分かりやすく勉強になりました。

アーカイブが公開されていますので、気になった方は視聴してみてはいかがでしょうか。

以上、CX事業本部MAD事業部のYui(@MayForBlue)でした。