クラシック VM から Kubernetes によってオーケストレーションされたコンテナにインフラストラクチャを移行する方法

このブログ投稿は、その方法についてですチャートモーグルDigitalOcean のインフラストラクチャの最後の部分を廃止し、AWS への移行が完了したことを示します。

この旅は、通常の AWS 移行ではありませんでした。インフラストラクチャを従来の VM から Kubernetes によってオーケストレーションされたコンテナに移行する必要があったからです。

一連の記事では、次のような経験を共有します。

• AWS EKS (Kubernetes マネージド サービス) への旅。
• 私たちが遭遇した最も重大な障害のいくつか。
• 現在のスタックとツール。
• 私たちの今後のインフラ計画は、コミュニティ全体に役立つことを願っています。

DigitalOcean のある生活

2014 年の創業以来、2021 年半ばまで、インフラストラクチャ全体が DigitalOcean ドロップレット (セルフマネージド クラウド仮想マシン) で実行されてきました。迅速、確実、かつ費用対効果の高い方法で業務を開始するには、クラウド プロバイダーが必要でした。

DigitalOcean は非常に理にかなっていて、素晴らしい選択でした。私たちは彼らのおかげで今いる場所にいます。この選択により、スケーラビリティやインフラストラクチャの複雑さ (通常は後の段階で発生する側面) を心配することなく、自由に製品の構築に専念することができました。

当社のインフラストラクチャのすべての側面は、社内でプロビジョニング、構成、および管理されていました。構成管理と Infrastructure as Code ツール (Saltstack と Terraform) を使用して物事を管理しました。

私たちは何年にもわたって成長を続けており、2019 年までに、管理、ソフトウェアの更新、セキュリティ パッチなどを常に必要としている約 50 台のマシンのフリートを見ていることに気付きました。また、パイプラインに新しいプロジェクトがあるため、2020 年末までにコンピューティング能力が 2 倍になると予想していました。

なぜ移動し、なぜ今なのか?

DigitalOcean は素晴らしい選択だったので、私たちの有機的な成長は、何年にもわたって私たちのセットアップの境界を押し広げていました。私たちは複数の分野で課題に直面しました。修正可能で予防可能なものもあれば、そうでないものもありました。

いろいろな失敗

• 突然生産を停止したアドホックの予告なしのメンテナンス期間。

  
  

• 何度かハードウェア障害が発生し、プライマリ データベースとレプリカ データベースのセットアップに影響を与えました (たとえば、ドロップレットが予告なしに「他のハードウェア マシンへのライブ マイグレーション状態」に入った場合、そのドロップレットに 1 ～ 2 時間のダウンタイムが発生しました)。

  
  

• DigitalOcean のサポート チームが解決できなかった、マシン間のレイテンシに関する原因不明のネットワークの問題 (これは、Postgres リードレプリカのラグ、Redis インスタンス、および HA 全般にとって重要でした)。

AMS2 リージョンの廃止

当社の DigitalOcean リージョン (AMS2) は、「まもなく廃止される」と発表されました。これは、サポートが限定されていることを意味します。必要に応じて追加のリソースを確保することはできませんでした。通常、単純なタスクを実行すると、計画に時間がかかり、リソースが無駄になりました。

Postgres のバージョンをアップグレードしたり、タスクを実行するために新しいマシンをプロビジョニングしたりするといった単純なことは、不可能になりつつありました。

限られたハードウェアの選択肢

サブスクリプション分析スペースにいるということは、データ集約型の操作、大容量、およびそれに応じて頻繁にスケーリングできることを意味します。

より広範なハードウェア リソースを備えた最新のマシンは、他の地域でしか利用できませんでした。ネットワーク パフォーマンスの低下は頻繁に発生していたため、別のリージョンに移行することが最善の策であることにすぐに気付きました。

最新のクラウド機能とマネージド サービスの欠如

インフラストラクチャを維持して成長率に追いつく (そして同時に技術的負債に対処する) ための運用作業の量が増加しました。

セットアップをよく見て、別の DigitalOcean リージョンに移動するか、新しいクラウド プロバイダーに移動することが最善の選択であるかを理解する必要がありました。

私たちはとどまるべきか、それとも行くべきか?

私たちは、DigitalOcean にとどまり、単純に新しい地域に移動することの利点を検討し始めました。

しかし同時に、私たちはこの動きを、予想されるユーザーの増加と進行速度の向上に合わせて、スタックの一部をモダナイズする機会として扱いました。

私たちの評価の終わりまでに、私たちは、特定の必須要件は、リージョンを維持して単に切り替えるだけでは達成するのが難しいことに気付きました.最も重要なものは次のとおりです。

• コンピューティング リソースの自動スケーリングの柔軟性。

• 管理されたデータベース。

• 一時的な使用に基づくリソースのプロビジョニング。

• より低い（より）レイテンシー。

• サービスの相互運用性。

• Kubernetes オーケストレーションによるコンテナベースのインフラストラクチャ。

  
  

この要件のリストと、前のセクションで示した課題により、プロバイダーの切り替えに有利な規模になりました。

AWS を選ぶ理由

ChartMogul インフラストラクチャを強化する新しいクラウド プロバイダーの選択は、長い道のりでした。私たちは市場を調査し、新しいプロバイダーがもたらす可能性のある多くのトレードオフと利点を発見しました.

私たちの選択肢は、Amazon Web Services (AWS)、Google Cloud (GCP)、および Azure でした。最終的に、AWS を使用することにしました。主な理由のいくつかを以下に示します。

チームの専門知識

本番環境ではすでにいくつかの AWS サービスを使用していました (たとえば、Postgres の増分バックアップを保存するための S3 など)。さらに重要なことに、当社のエンジニアの何人かは、本番システムでさまざまな AWS サービスを広範囲に使用した経験がありました。

スケーラビリティ

• ボタンを押すだけで、AWS インスタンスを増減できます。

  
  

• RDS データベースなどのリソースを即座にプロビジョニングし、リソースを一時的に計算できます。

  
  

• 実験と概念実証をすばやく繰り返すことができます。

  
  

• EC2 の自動スケーリングによってバックアップされる Kubernetes ノード プールの柔軟性とスケーラビリティに勝るものはありません。

データのセキュリティとコンプライアンス

データのセキュリティは常に最優先事項です。何年にもわたって、AWS のセキュリティ機能は大幅に向上しています。

データ セキュリティに関して AWS が開発した新しいサービスの数は、コンテナ/Kubernetes スペースでの私たちのニーズのほとんどをカバーしています。

プライベート VPC 分離、ポリシーのきめ細かな制御、IAM ロールなどの確立されたサービスとうまく連携します。

コンプライアンスに関しては、私たちはできるだけ早く SOC II 認定を取得する予定であり、AWSコンプライアンスプログラムがその旅を迅速に進めるのに役立つ利点であることがわかりました.

マネージドサービス

Postgres は、私たちが ChartMogul で行っていることの中心であり、通常、私たちの成長をサポートするために、マシンのデータベース フリートを積極的に管理することに多くの時間を費やしてきました。

データベースの高可用性と信頼性に対する関心が高まっていたため、マネージド PostgreSQL を使用する主要なクラウド プロバイダーからの複数のオファーを評価することにしました。 AWS RDS が明らかに勝者でした。

マネージド Kubernetes は、考慮すべきもう 1 つの主要な要素であり、これは Google Cloud (GCP) と真っ向から対立していました。 Google のマネージド Kubernetes (GKE) は、当時の AWS よりも優れているように感じましたが、RDS と CloudSQL を比較すると、機能面ではあまり似ていませんでした。

しかし最近では、AWS が EKS に追いついているようです。スナップショットの柔軟性、バックアップの耐久性 (SLA を使用)、Postgres のリードレプリカ、簡単なアップグレード、専用 IOPS、Cloudwatch メトリクス、Performance Insights などの優れた RDS 機能の恩恵を受けています。

非常識な数の AWS サービス

執筆時点で、AWS は 200 以上のサービスを提供しています。それらのほとんどは、コンピューティング、データベース、データ分析、データ ウェアハウジング、サーバーレス、ストレージなど、非常に多くの分野からマネージド サービスに即座にアクセスできるようにします。

当社のエンジニアリング チームは、最先端の統合を活用して主要な問題を迅速に解決し、購入よりも合理的な場所での構築を優先できるようになりました。

災害からの回復

AWS クラウドは、災害復旧計画の不可欠な部分です。その理由は、インスタンスの起動が簡単で、ボタンをクリックするだけで RDS リードレプリカをプライマリに昇格でき、スナップショットが簡単で、複数のリージョンでホストでき、IaC ツールとの最高の統合があるからです。選択。

AWS クレジット

AWS スタートアップ プログラムを通じて、10 万ドル相当のクレジットを確保しました。多額の費用をかけずに、移行を計画、テスト、および完了することができました。

AWS への移行

DigitalOcean から AWS への移行は、10 か月に及ぶ旅でした。すべての取り組みは、すべてのエンジニアリング チームのボランティアによって支えられ、DevOps エンジニア、バックエンド エンジニア、エンジニアリング責任者によって推進されました。

試行錯誤を伴うものもありました。次の複数の方法を試しました。

• ほぼゼロのダウンタイムで Postgres から RDS にデータを移動します。

  
  

• アプリとサービスを VM ベースのアーキテクチャから Kubernetes のコンテナー化されたアーキテクチャに移行します。

  
  

• 展開方法を根本的に変更します。

完璧な計画が立てられており、紙の上ではすべて順調に進んでいるように見えましたが、物事が常に計画どおりに進むとは限らないという難しい方法を学びました。

ダウンタイムがゼロに近い移行の目標が深刻なリスクにさらされることもあり、最初からやり直すこともありました。

忍耐力、意欲、素晴らしいチームの努力により、私たちは直面した課題を克服することができました。

慎重な計画も驚異的でした。私たちのキャパシティを考慮して、実際の移行を 3 つの段階 (または数日) に分割するのが最適であることを早い段階で確立しました。

週前の D デー

• DigitalOcean から RDS インスタンスへの Postgres レプリケーションを開始します。
• AWS の将来の本番インフラストラクチャを確認してください。
• シークレットの構成 (AWS パラメータ ストア)。
• CI/CD パイプラインを新しい Kubernetes クラスターにデプロイする準備ができていることを確認します。

D-Dayの前日

• AWS temp webhook レコーダー インフラストラクチャを準備します (移行中にイベントが失われることはありませんでした)。

  
  

• 一部のデータを事前に移動します (たとえば、DigitalOcean Spaces を S3 に移動します)。

  
  

• すべての Parameter Store シークレットを本番環境の値に更新します。

  
  

• DNS の変更を準備します。

  
  

• すべての Kubernetes デプロイメントをゼロ ポッドに設定して、移行中にサービスが本番データにアクセスできないようにします。

D-day：スイッチをフリック

• すべての Webhook を AWS 一時レコーダーにリダイレクトします。

  
  

• DigitalOcean のすべてのサービスを停止します。

  
  

• Postgres レプリケーションが最新の更新に追いつくまで待ちます。

  
  

• DigitalOcean と RDS Postgres のデータを比較します (整合性とレプリケーションが確実に追いつくようにするため)。

  
  

• RDS から DigitalOcean で実行されている Postgres へのサブスクリプションを削除します。

  
  

• RDS リードレプリカを作成します。

  
  

• Parameter Store シークレットを新しい RDS エンドポイントとシークレットで更新します。

  
  

• Kubernetes にデプロイし、PgBouncer を再起動して新しい構成を読み込みます。

  
  

• app.chartmogul.comの DNS レコードを AWS に切り替えます。

  
  

この時点で、光沢のある新しいインフラストラクチャで本番ワークロードを実行していました。すべてを 10 時間で完了しました (最初は 8 時間と見積もっていましたが、それほど悪くはありません)。

AWS の課題

最大の苦労は、DMS サービス (データベースを RDS に移行するための AWS マネージド サービス) に関するものでした。

宣伝されているほど使いやすくはありませんでした。 Postgres の場合、これは役に立ちませんでした。最終的に、データを AWS に移動する独自の方法を開発しました。

また、Webhook をサポートする AWS にダウンタイムなしでデータベースを移行するのは複雑であることも痛感しました。このセットアップをサポートするカスタム アプローチを開発しました。

これらのカスタム アプローチについては、今後の記事で詳しく説明します。

シリーズの今後の記事

DigitalOcean から AWS への移行の過程を記録した今後の記事にご期待ください。次のようなトピックに触れます。

• ChartMogul を強化するために Kubernetes を選んだ理由。
• PostgreSQL を RDS に移行した方法。
• Rails アプリを Kubernetes に移行した方法。
• AWS VPC への IPSEC トンネルをセットアップする方法。