🐭

【GCP/Next.js】Cloud Runを使用したインフラ構築

6 min read

概要

本記事では、GCPにおけるCloud Runを活用したインフラ構築について解説しています。Cloud Runだけでなく、インフラの全体をアーキテクチャ図で解説しつつ、具体的な構築方法も掲載していますので、ぜひ参考にしてもらえればと思います。

サーバーとかインフラについてあまり詳しくないけど、触れてみたいという方もいると思います。今回もできる限り、初見さんでも理解できるぐらいに噛み砕いて書いていこうと思います。

はじめに

本記事では、Next.js×Cloud Runのインフラ構築例を紹介します。基本的に構築方法は、他のフレームワークや言語でも活用できますが、要件定義によって利用するサービスが変わることがあります。今回は構築の一例であることをご理解の上、参考にしていただけると幸いです。

また、今回使用するコンテナイメージについては、こちらの記事で紹介しているものを使用します。本記事を参考にする際にはこちらも合わせてご確認ください。

記事構成について

本記事では、インフラ構築の概要だけ触れます。実際の導入方法については、記事の読みやすさを重視するため、1記事1テーマに絞って解説していく予定です。今後の記事に関しては以下の予定で公開したいと考えています。

執筆予定の記事一覧

  • Cloud Runにできるだけ短時間で自動デプロイ
  • Cloud DNSでIPアドレスとドメインを対応付ける方法
  • Cloud RunのHTTPリクエストを固定IPにする方法
  • Cloud Runにおけるセキュリティ対策
  • Cloud Load Balancing × Cloud CDNを用いたサイト高速化
  • Cloud Armorを用いた不正アクセス対策について

こちら予定ですので、変更になる可能性があります。予めご了承ください。

利用するサービス

今回、使用するGCPのサービスは以下の通りです。実際に運用する際は、機密情報を管理するKMSやCloud RunのIPアドレスの固定をする際に使用するVPCNATなどのサービスもありますが、今回はできる限り、多くの人に理解を深めてもらいたいため、最低限のシンプルな構成にしています。前述のサービスを組み込んだ構成に関しては、別途記事にする予定ですので、気長にお待ちいただけると幸いです。

Cloud Run

Cloud Runとは、GCPにおけるサーバーレスサービスの1つでデプロイしたコンテナをフルマネージド環境で動作させることができます。もう少し噛み砕いて表現すると「コンテナをサーバーレスで実行するサービス」と言った感じでしょうか。
類似サービスにCloud Functionsが存在していますが、こちらはPythonやNode.jsなど限られたプログラミング言語以外は動作させることができません。対してCloud Runは、コンテナをデプロイするため、コンテナで選択したプログラミング言語を使用でき、より柔軟な実装が可能です。

Cloud Run vs Cloud Functions
Cloud RunとCloud Functionsの比較表

特徴

  • コンテナで動作させるため、言語やライブラリの制約がない
  • App EngineやCloud Functionsに比べて高速でデプロイできる
  • コードが実行されている間のみ料金が発生する従量課金
  • 他のGCPサービスとの親和性が高い
  • カスタムドメインの設定ができる
  • 高速に自動スケーリングできる
  • 任意にトラフィックを分割できる

https://cloud.google.com/run

セキュリティについては、後日公開予定の「Cloud Runにおけるセキュリティ対策」の記事で解説する予定です。

Cloud DNS

Cloud DNSとは、GCPが提供しているDNSサービスです。そもそもDNSとは、Domain Name System(ドメインネームシステム)の略称で、「ドメインネームとIPアドレスを結び付けるシステム」のことを示します。DNSを使用しないとサーバーに割り振られたIPアドレスでしかアクセスできないため、任意のドメインにアクセスさせたい場合には、「192.0.0.0」などで示されるIPアドレスとドメインをDNSを使用して紐付け・変換する必要があります。

Cloud DNS

特徴

  • Google と同じインフラストラクチャで動作
  • 100%の可用性と自動スケーリング
  • 柔軟に公開設定できるDNSゾーン

https://cloud.google.com/dns

DNSについては、後日公開予定の「Cloud DNSでIPアドレスとドメインを対応付ける方法」の記事で解説する予定です。

Cloud Load Balancer

Cloud Load Balancerとは、GCPにおける負荷分散サービスです。そもそもLoad Balancer(以降、負荷分散)とは、システムの可用性と処理速度の向上を目的としています。負荷分散を導入することでサイトへのアクセス集中やサーバー不具合が発生した場合でも、アクセス中の利用者に安定したサービス提供を継続可能になります。簡単にまとめると「処理を適切に振り分けて誘導するサービス」です。

Cloud Load Balancer

特徴

  • 自動スケーリングと負荷分散
  • HTTPSトラフィックを複数のリージョン/インスタンス間で分散
  • シームレスな自動スケーリング
  • Cloud CDNとの統合が容易
  • Cloud Armorとの連携によるセキュリティ対策
  • 負荷分散リクエストのログを記録

https://cloud.google.com/load-balancing

詳しい内容については、後日公開予定の「Cloud Load Balancing × Cloud CDNを用いたサイト高速化」の記事で解説する予定です。

Cloud CDN

まずCDNとは、どういうサービスなのか解説します。CDNとは、Contents Delivery Network(コンテンツデリバリーネットワーク)の略称で、簡単にまとめると「効率的かつ高速でコンテンツを配信可能にするネットワークサービス」です。具体的には、 HTML、CSS、JavaScriptなどの静的なコンテンツを地理的に分散したキャッシュサーバーから配信することで、ユーザーが世界のどこからでも高速でアクセスできる状態を実現できます。

そんなCDNサービスをGCPでは、Cloud CDNとして提供しています。Cloud CDNは、基本的に前述のCloud Load Balancerと併用します。

Cloud CDN

特徴

  • 信頼性の高いGoogleのインフラ上で配信できる
  • 他のGCPサービスとの親和性が高い
  • リクエストのログを記録
  • SSL証明書の取得や更新が追加コスト無しで利用可能

https://cloud.google.com/cdn

詳しい内容については、後日公開予定の「Cloud Load Balancing × Cloud CDNを用いたサイト高速化」の記事で解説する予定です。

Cloud Armor

Cloud Armorとは、GCPにおけるクラウド型WAF(Web Application Firewall)です。一言で表すなら「ネットワークのセキュリティ対策サービス」といったところです。DDoS攻撃対策やIPアドレスによる通信制限、WAFルール等のセキュリティ機能を備えたサービスで、攻撃時にはログが収集されるため、分析・対策をすることが可能です。
また、Cloud Armorは前述のCloud Load Balancerの付加機能です。そのため、セキュリティ機能は全てサーバ外(Edge)で処理され、Cloud RunやApp Engine等のサーバーに負荷がかかることはありません。

Cloud Armor

特徴

  • GmailやYouTubeなどGoogleの大規模サービスにおける実績
  • インフラに対するDDoS攻撃の検出と軽減
  • 各種攻撃のログを記録
  • IPアドレスや位置情報に基づくアクセス制御が可能

https://cloud.google.com/armor

詳しい内容については、後日公開予定の「Cloud Armorを用いた不正アクセス対策について」の記事で解説する予定です。

お名前.com(外部)

お名前.comは言わずと知れたドメイン登録サービスで、今回唯一GCP外のサービスです。GCPにもCloud Domainsというドメイン登録サービスがありますが、一般提供が最近で利用している方があまり多くないと考え、今回はお名前.comを採用しました。ただ、同サービス内ということもあり、簡単に連携できるようなので、いつか別記事でCloud Domainsを使用した方法も紹介できればと思います。

https://www.onamae.com/

構成

Before

After

構成はシンプルのため、構築コストや運用コストは比較的低めになりますが、多々問題点があります。エンドユーザーがサーバーに直接アクセスしているため、サーバーにかかる負荷が重いことに加え、不正アクセスなどの攻撃に対して脆弱性があります。また、サーバーの設置されている場所から物理的に距離が離れてしまうと、アクセスに時間がかかってしまうため、ユーザー体験にも影響が及びます。

After

Before

Beforeとの主な違いは、Cloud Load Balancerを中心としたEdge層での処理が追加されている点です。Cloud CDNでサーバー(Cloud Run)に対する負荷を下げつつ、ユーザーに対して高速でコンテンツを提供できるようになっていることに加え、Cloud Armorで不正アクセスやDDoS攻撃に対しても対応できるため、セキュリティとパフォーマンスの双方を担保できる構成になっています。運用にかかるコストは増加しますが、攻撃などによるリスクを軽減できます。

構築の手順

  1. お名前.comでドメインを登録して取得する
  2. Cloud Runでアクセス制限の設定をする
  3. Cloud RunとCloud Load Balancerを連携させる
  4. Cloud Load BalancerでSSL証明書を設定する
  5. Cloud Load BalancerでCloud CDNを有効化させる
  6. Cloud Load BalancerでCloud Armorを有効化させる

具体的な導入方法については、フェイズ毎に分けて(4~5記事)解説していく予定です。

まとめ

今回は、Cloud Runを使用したインフラ構築の概要を解説しました。インフラ構築はサービスを運用する上で、非常に重要な部分の一つです。インフラ構築を疎かにすると予期せぬ攻撃で障害が発生するだけでなく、ユーザーに対して安定した配信ができなくなったりと様々な問題がでてきます。苦手意識を持つ人も多いと思いますが、本記事で少しでも理解を深めることができていれば幸いです。

次回からは、実際にインフラを構築する方法を解説していきます。とりあえず次回は、Cloud Runにコンテナをデプロイする方法を解説していく予定です。

いいねしていただけると記事執筆の励みになりますので、参考になったと思った方は是非よろしくお願いします!

関連記事

https://zenn.dev/kazumax4395/articles/427cc791f6145b

参考記事

https://www.topgate.co.jp/gcp30-cloud-cdn
https://www.topgate.co.jp/cloud-run-2021

Discussion

ログインするとコメントできます