DoiT acquires SELECT to optimize Snowflake and BigQuery
Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

AWS・CloudflareからGoogle Cloudへ、段階的に移行する

By Mike SparrJul 24, 20204 min read

このページはEnglish、Deutsch、Español、Français、Italiano、Portuguêsでもご覧いただけます。

1 5bed mq0 o idipajeoeeq

テクノロジースタックのクラウドネイティブ化を進める企業のあいだで、フル移行への中間ステップとして、部分的なクラウド移行やハイブリッドクラウド構成を選ぶ動きが広がっています。

1 5bed mq0 o idipajeoeeqクラウド移行

先日、あるEコマース企業が、GoogleのマネージドKubernetesサービスであるGKEを利用するため、コンテナ化されたアプリケーションをAWSからGCPへ移行していました。

同社の商品カタログのファイルや写真はAmazon S3のオブジェクトストレージに保管され、DNSはAWS Route 53で管理、CDNはCloudflareを利用していました。最初のステップとして、データベースを移行し、Kubernetesクラスタにアプリケーションを並行デプロイしました。

続くステップで求められたのは、CDNをCloudflareからGoogleのものへ切り替えつつ、静的ファイルは当面S3に置いたままにすること。さらに、現在AWS Route 53で管理しているDNSをそのまま活かすことも条件でした。

1 026zc1ira fmkpbvfsvnvaEコマース企業における多段階クラウド移行の例

本記事では、ロードバランサーとネットワークエンドポイントグループ(NEG)を使い、AWS S3バケットのコンテンツをGCP Cloud CDNでキャッシュする方法を、手順を追って紹介します。今回は説明を簡潔にするためSSL証明書の発行とHTTP(S)フロントエンドの追加は省きますが、実運用ではこれらが追加で必要になるのが一般的です。

デモ環境のセットアップ

  1. テスト用ファイルを置く初期S3バケットを作成

1 c vaijadbpltbzuj0mxsywS3バケットを作成(後でLBのホスト設定に使うため、バケット名を控えておきます)

2. テストファイルをアップロードし、メタデータを編集してCache-controlヘッダーを追加

1 bouyayivba1gkv1nd9t0 qアップロードしたサンプルファイル1 ac7a0jibnz bqyntrmvqvaCache-controlヘッダーを追加(CDNでは必須)

3. コンテンツが正しいヘッダーを返すかテスト

1 b3jjtc2i5 lt ankiwxsg

GCPでロードバランサーとNEGを構成する

  1. バックエンドタイプとして「 Internet network endpoint group」を追加または編集

1 9zwv88uiv9 myanbui45xg

2. ネットワークエンドポイントグループ(NEG)を選ぶか「新規作成」

注意: ロードバランサーのバックエンド設定のドロップダウンにNEGを表示させるには、先にネットワークエンドポイントグループ(NEG)を作成しておく必要がある場合があります。表示されない場合は「Create Internet network endpoint group」から作成できますが、ロードバランサー画面を更新しないと反映されません。

1 ezk31kmoaw2keaxrdqziq1 9d1mnibgzb49tsigoqp8lg

「Fully qualified domain name」を選択し、S3バケットのFQDNを入力します(これを指す独自のDNSエントリがあれば、そちらでも問題ありません)。

3. Cloud CDNを有効化し、カスタムヘッダー(S3バケットのホスト名と一致)を追加

外部NEG用に「Backend type」を選んだら、「Enable Cloud CDN」にチェックを入れ、画面下部のオプションを開いてカスタムヘッダーを作成します。

ポイントは、下図のように S3ホスト名と一致するカスタムホストヘッダーを追加することです。

1 35ujn8o989bghw4ezlkglq

4. フロントエンドを追加または編集

1 aa2kpqu0rgzdnu7hnldqeg

5. ロードバランサーを保存し、NEGが設定されていることを確認

1 i4jzz90vnunwqgmg2nom1g1 3ticjqy8iuc1aprafxduja

6. コンテンツが返ってきてキャッシュにヒットしているかテスト

1 mcaoahpcffdwuuynd1tcnwコンテンツに到達できることを確認(ブラウザからでも可)

ブラウザで数回アクセスしたあと、ログ(手早く確認するならStackdriverログ)でエントリを開き、キャッシュ経由で返されていることを確認します。

1 ein6zkgefcaodjziopt5jaロードバランサー経由のトラフィックでキャッシュが機能していることを確認

DNSエントリを更新してトラフィックをCloud CDNへ切り替える

すべてが想定どおりに動き、コンテンツがキャッシュから配信されていることを確認できたら、あとは準備が整い次第DNSエントリを書き換えるだけです。

今回のケースでは、CDNはCloudflareが提供しており、DNSエントリ cdn-environment-location.myco.com がCNAME something.cloudflare.com を指していました。新しいAレコードをGoogleロードバランサーの外部IPに向けて作成し(例:gcp-lb-development-cdn.myco.com)、CNAMEをその新しいエントリに差し替えれば完了です。

念のため、前日のうちに本番CDNエントリのTTLを必要に応じて短めにしておくことをおすすめします。こうしておけば、万一トラブルが起きてCNAMEを切り戻すことになっても、クライアント側のDNSキャッシュが長く残らずに済みます。

手順のまとめ:

  1. 既存CDNドメインのTTLを短縮する
  2. GCPロードバランサーのIPを指すAレコードを追加する
  3. 既存CDNドメインのCNAMEレコードを編集する(CloudflareのFQDNを置き換え)
  4. Cloud CDN経由でコンテンツが配信されているかテストする

1 36cbq8s2saasb8qcm2l76aお疲れさまでした、これで完了です!次はHTTP(S)フロントエンドでセキュア化しましょう ;-)

クラウド構成のコストにも目を向ける

Cloud CDNからS3バケットへのリクエストをプロキシすることは可能ですが、その実現にはカスタムヘッダーの追加が必要で、これには費用がかかります。現状の料金は100万リクエストあたりおよそ$0.75で、月額上限は$500です。トラフィックの多い大規模サイトでは、無視できない額になることもあります。

Cloudflareに支払う料金(金額は不明)に比べれば軽微かもしれませんが、把握しておきたいポイントです。長期的には静的ファイルをGoogle Cloud Storageバケットへ移行する計画で、こちらは同じS3 APIをサポートしているため、コード変更はほとんど(あるいはまったく)不要です。

まとめ

ご覧のとおり、テクノロジープロバイダー間の移行は、想像するほど大ごとではありません。ただし、より安全なのは作業を小さなフェーズに分けて進める方法です。問題が起きてもすぐにロールバックでき、業務への影響を最小限に抑えられます。