トップ > Infra > 第10回:Cloudflareの紹介と運用のポイント

第10回:Cloudflareの紹介と運用のポイント

Infra Technology 連載記事

※本記事は、技術評論社「Software Design」(2024年1月号)に寄稿した連載記事「Google Cloudを軸に実践するSREプラクティス」からの転載1です。発行元からの許可を得て掲載しております。

はじめに

前回はDatadogによるクラウド横断のモニタリング基盤について解説しました。 今回はCloudflareとは何か、なぜ使っているのか、各サービスとポイント、キャディでの活用例を紹介します。

▼図1 CADDiスタックにおける今回の位置付け

Cloudflare とは

本記事では、Cloudflare社が提供しているプラットフォーム全体を「Cloudflare」とします。 Cloudflareは、ひと昔前までは数あるシンプルなCDN(Contents Delivery Network)サービスの1つでした。CDNとは、コンテンツの配信を最適化するためのネットワークです。コンテンツキャッシュを利用して、エンドユーザーにより早く効率的にコンテンツを配信できます。 近年、CDN事業者が提供するサービスは、単なるCachingやLoad Balancingだけではなくなってきています。Edge Cloud/Edge ComputingやSecurity領域など、Webアプリケーションのネットワーク上の“Edge”であることを活かしたさまざまなサービスを展開しています。その中でもCloudflareは、筆者の知る限り、最も先進的で幅広いスコープのサービスを提供するプラットフォームです。 執筆時点では、Cloudflare社は提供しているプラットフォーム全体をコネクティビティクラウドと呼んでいます。また、それを構成する要素として次の3つのサービスがあります(図2)。

▼図2 Edge ServerとOrigin Server

なぜCloudflareか

キャディでは2019年にコーポレートサイト(Origin Server)の負荷を下げるためのCDNとしてCloudflareを使い始めました。理由は単純で、非常に安い費用で利用開始できたからです。 費用が安いことはCloudflareの大きな魅力の1つで、無償から使えるさまざまなサービスを提供しているため、個人開発での利用にもお勧めです。きっかけこそCDNとしての費用が理由ではありましたが、現在はCDN以外のさまざまなサービスを利用しています。 筆者が過去に所属していた企業では、AkamaiやFastlyを利用していました。とくにFastlyは、Developer Friendlyで、柔軟かつ積極的なキャッシュ戦略をとれるのが魅力です。それが大量のコンテンツを配信するB2Cのサービスにはマッチしていて重宝していました。 一方、キャディはB2Bのサービスを提供しており、要件的にそれほど高度なキャッシュ戦略を必要としていません。そのため今となっては「先進的で幅広いサービスを提供しているプラットフォームで、それが事業にマッチしているから」という理由にとらえなおしています。

各サービスの紹介とポイント

誌面の都合上、Cloudflareのサービスを網羅的に紹介することは難しいので、いくつかピックアップしてポイントを解説します。

Cloudflare DNS

Cloudflare DNSは一部機能を除いて無償で使えるDNSサービスです。 Cloudflare DNSを使ってDNS Recordを管理すると、図3のように設定画面上にProxy statusが表示され、このフラグをON(Proxied)にすることでEdge Serverへ向き先が変わります。nslookupすると、Proxy statusの状態によって返ってくる値が違うことを確認できます。DNSの設定はoctoDNSやTerraformでIaCしておくことをお勧めします。 また、Business Plan以上であれば、任意のDNSプロバイダでCNAMEを指定してEdge Serverへプロキシできます。つまり、Cloudflare DNSの利用は、Cloudflare CDNを使うための必須条件はでありません。

▼図3 DNS Recordの画面

Origin Serverの保護

前述のとおり、Cloudflare DNSのProxy statusを変更するだけで、リクエストを簡単にEdge Server経由に切り替えられます。とはいえ、より安全かつ効率的に運用していくための準備が必要です。その準備の1つとして「Origin Serverの保護」について触れておきます。 前提として、Edge Server側でさまざまな最適化をするためにEdge Serverを経由させたいので、Origin Serverへの直接アクセスされるとその最適化が効かなくなってしまいます。仮にOrigin Serverの場所がユーザーや攻撃者に漏れてしまっても、そのリスクを最小化するために「Origin Serverの保護」が必要です。具体的には、Origin Server側がEdge Serverを経由していないリクエストをブロックしたり、Cloudflareへの専用接続を作ったりします。方法には次のようなものがありますが、やり方によってセキュリティレベルや実装難易度、費用が変わってくるので、提供するプロダクトの要件しだいでどれを選択するか決めましょう。

  • アプリケーションレイヤ
    • Cloudflare Tunnel (HTTP / WebSockets)
    • HTTP Header Validation
    • JSON Web Tokens (JWT) Validation
  • トランスポートレイヤ
    • Authenticated Origin Pulls
    • Cloudflare Tunnel (SSH / RDP)
  • ネットワークレイヤ
    • Allowlist Cloudflare IP addresses
    • Cloudflare Network Interconnect
    • Cloudflare Aegis

「Cloudflare Tunnel」は、暗号化されたCloudflare専用の接続を構築することで、Origin Serverへの入口を非公開にできます。「HTTP Header Validation」は、Edge Serverで任意のヘッダを付与し、Origin Serverでそのヘッダがあるもののみ受け入れます。「JWT Validation」は、Cloudflare Access(後述)で付与された正しいJWTかどうかを検証して受け入れます。「Allowlist Cloudflare IP addresses」は、アクセス元が公開されているCloudflareのIPだったときのみ受け入れます。 手軽にやりたい場合は、「HTTP Header Validation」や「JWT Validation」がお勧めです。 Web Application Frameworkのミドルウェアで検証してもよいですが、Backend Applicationより前のレイヤで検証して関心事を分離するのもよいでしょう。GKE の場合、Service Mesh(Envoy)で検証できます。CloudRunの場合でもサイドカーが実装できるようになったので、同様にEnvoyでの検証ができます。Google Cloud Armorを使う場合、「Allowlist Cloudflare IP addresses」が選択肢の1つになるでしょう。しかし、Cloudflare WAF(後述)を使う場合、WAFが重複してしまうことや、最新のCloudflareのIPに追従する機能の費用が高いことに注意が必要です。 そのほかの準備や詳細は、公式のGettingStartedを参照してください。

証明書

Edge Serverの証明書は、デフォルトではCloudflareが発行したManagedな証明書を利用します。もちろんすでに別途発行済みの証明書をアップロードして使うこともできます。 また、「クライアントとEdge ServerとOriginServer間」の通信を常に暗号化しておくため、encryption modes(暗号化モード)をFull以上にして、Origin Serverの証明書を設定しましょう。暗号化モードがFull未満の場合、「クライアントとEdge Server間」「Edge ServerとOriginServer間」のどちらか、または両方が暗号化なしで接続されます。 CloudflareにはOrigin CA(CertificateAuthority)証明書の発行機能があるので、それを利用するのがお勧めです。Kubernetesを使っている場合、cert-managerとOrigin CAIssuerを使って証明書の発行を自動化できます。

Cloudflare Cache

Cloudflare Cacheは、Cloudflare CDNのコア機能です。コンテンツをEdge Server側でキャッシュすることにより、Origin Serverの負荷を下げつつ、エンドユーザーにより早くコンテンツを配信します。 基本となるデフォルトのキャッシュ動作は次のとおりです(もちろんカスタマイズにより、ほかのルールや設定にオーバーライドされる可能性があります)。

キャッシュされないケース:

  • ache-Control ヘ ッ ダ に「private」「no-store」「no-cache」「max-age=0」が設定されているとき
  • Set-Cookieヘッダが存在するとき

キャッシュされるケース:

  • Cache-Controlヘッダがpublicに設定され、max-ageが0より大きいとき
  • Expiresヘッダが未来の日付に設定されているとき

デフォルトでは、HTMLはキャッシュされず定義されているファイルの拡張子をもとにキャッシュされます。たとえばJS/CSS/JPG/SVG/CSV/ICOなどが対象です。 実際のレスポンスがキャッシュされたものかどうかを確認するには、CF-Cache-Statusヘッダを参照します。ヘッダの値がHITであればEdge Serverにキャッシュされたコンテンツであり、MISSであればOrigin Serverから返されたコンテンツです。 Edge Serverのキャッシュを削除(パージ)したいときは、Cloudflare DashboardやWeb APIのどちらからでも実行可能です。ただし、Enterprise Plan以外はURL単位でしかパージできません。たとえば、Webアプリケーションのデプロイ時に特定領域のキャッシュをまとめてパージできると便利なのですが、Enterprise Plan以外はそのオプションを利用できません。 また、キャッシュパージ以外にも契約しているプランごとに表1のような制限があります。

▼表1 プラン別の制限内容

Free Pro Business Enterprise
HTTP POST Requestサイズ上限 100MB 100MB 200MB デフォルト500MB(変更可能)
キャッシュ可能なファイルサイズ上限 512MB 512MB 512MB デフォルト5GB(変更可能)
キャッシュパージの単位 URL URL URL URL,Hostname,Tag,Prefix

Web Application Security

Cloudflare CDN を利用すると、自動的にCloudflare WAFや Cloudflare DDoSProtectionが有効になり、セキュリティを強化できます。どちらも無償から利用可能で、プランをアップグレードするとより高度な機能が利用できます。WebアプリケーションやOriginServerを守るため、これらを使うだけでもCloudflare CDNを導入する価値が十分あります。 ビジネス用途の場合、Cloudflare WAFのOWASP Core Rulesetを有効にしておきましょう。これは、OWASPFoundationというセキュリティ向上に取り組むコミュニティが定義しているWAF用の攻撃検出ルールセットです。 プロダクトの運用開始後にWAFを設定するとき、ユーザー影響が心配であれば、適用範囲絞ったり、OWASP Anomaly Score Thresholdを低めに設定したりできます。 また、ルールを検出したときのアクションを設定しておくことができ、次の中から選択できます。Enterprise Planを契約している場合は、ルールを厳しめにしてからアクションをLogに設定してしばらく様子を見るのもありでしょう。

  • Block: アクセスをブロックする
  • Log: Cloudflare Logに書き込むだけ(Enterprise Planが必要)
  • JS(JavaScript) Challenge: ボットやスパム対策。リクエスト元がブラウザかどうかを判定する
  • Interactive Challenge: 人間が何らかの操作をすることで突破できる
  • Managed Challenge: リクエストに応じてほかのチャレンジを自動選択する

Cloudflare Access

Cloudflare Accessは、Cloudflare ZeroTrustを構成するサービスの一部です。ZeroTrust(ゼロトラスト)とは、従来のネットワークによる境界防御ではなく、情報資産に対するアクセスを信頼せずに必ず検証することにより防御するという考え方です。 Cloudflare Accessを利用すると、WebアプリケーションやSaaSに簡単に認証認可を付与できます。Public InternetからアクセスできないPrivate Network Applicationにも適用できます。また、Synthetic Monitoring(外形監視)やシステム間API連携などのために、保護されたアプリケーションにアクセスするためのサービストークン発行機能もあります。 キャディでは、開発用のSaaSやツール、社内向けWebアプリケーションへのアクセスのために活用しています。認証プロバイダ(IdP)にはGoogle Workspaceを使い、Google GroupsとWebアプリケーションをひも付けることで認可を制御しています。たとえば、特定グループに属する社員だけが当該アプリケーションにアクセスできるといった制御です。一時的に業務委託の方へ社内向けアプリケーションを公開したいときは、One-time PIN login(OTP)によるアクセスを許可するなど柔軟な設定ができます。OTPとは、認証ページでE-mailを入力し、送られてきたパスワードを入力して認証するログイン方法です。概要図は図4のとおりで、表2のようなアクセスポリシーで制御します。 ちなみに、Google CloudにはIdentity-AwareProxy(以降、IAP)というゼロトラストのアクセスモデルを実装できるサービスがあります。 要件によってはIAPを利用することで同等の認証認可を付与できますが、汎用性・柔軟性・メンテナンス性などの観点からCloudflare Accessをメインで使っています。たとえば、グローバルIPを持たないBastion Serverなど、Google Cloud内で完結させたほうがよいものはIAPを使って制御しています。

▼図4 Cloudflare Accessの概要図

▼表2 アクセスポリシー

Application Policy
Development Tool
Staging Environment
Sentry 		Allow Developer Group
Internal Application Allow Internal App Group
Allow outsourcing@example.com

Cloudflare Gateway

Cloudflare Gatewayは、Secure WebGatewayの実装の1つであり、Cloudflare Accessと同様にCloudflare Zero Trustを構成するサービスの一部です。Secure Web Gatewayとは、安全な外部通信をするために、URLフィルタリングやマルウェア検出/ブロック、アクセス制御などを行うゲートウェイ(プロキシ)のことです。 図5がCloudflare Gatewayを使用したときの概要図です。まず、エンドユーザーの端末とCloudflare Gateway間において暗号化された専用接続を構築します。具体的には、WARPというクライアントをインストールします。 WARPを有効にすると、Webの通信がすべてCloudflare Gatewayにプロキシされます。 Cloudflare Gateway側では、DNS、HTTP、Networkのそれぞれのレイヤでフィルタリングルール(ポリシー)が適用されます。企業の管理者は、ポリシーを設定しておくことで、各レイヤごとにマルウェアやフィッシングをブロックしたり、特定のグループのみに特定のアプリケーションへのアクセス権を与えたりできます。 また、アンチウイルススキャンの設定を有効にしておけば、ダウンロードしようとしているファイルにもマルウェア検知とブロックを実行できます。

▼図5 Cloudflare Gatewayの概要図

Cloudflare Rules

Cloudflare Rulesを使うと、Edge Server側にて任意の条件でリクエストやレスポンスを変更できます。一例として、図6のようにリダイレクトルールのAPIを利用し、プロダクトごとに計画メンテナンス用の画面に切り替えができるように、共通の開発者向けアプリケーションを構築しています。 また、執筆時点でGAになっていませんが、Cloudflare SnippetsによりJavaScript でルールを書けるようになるため、さらに柔軟な変更が可能になりそうです。

▼図6 計画メンテナンス管理の概要図

実行順序

これまで紹介したとおり、CloudflareではEdge Server側でさまざまな最適化ができます。 しかし、利用する機能が増えてきたときには注意が必要です。どの機能がどの順序で処理されるかを意識しておかないと、設定したときに想定外の挙動になりかねないためです。Cloudflareのダッシュボードから各機能の設定画面でTraffic Sequenceを確認できます(図7)。初めて利用する機能の設定をするときには、既存の設定との副作用や考慮漏れがないかをチェックしましょう。 執筆時点ではまだBetaの機能ではありますが、Cloudflare Traceを利用すると便利です。 Cloudflareのダッシュボード上でリクエストをカスタマイズして実行し、そのリクエストにどの設定が適用されるかシミュレートできます。

▼図7 実行順序

Developer Platform

CloudflareにはWebアプリケーションを構築するためのコンポーネントが一通りそろっています。多くのサービスが無償から利用できます。Cloudflare Workersはエッジコンピューティングの実装の1つであり、FaaS/Serverlessでもあります。次のような特徴があり、使い勝手が良いため、キャディの一部プロダクトでも利用しています。

  • 非常に安価
  • 高いスケーラビリティ
  • 開発者体験がよい
  • 0ms Cold Start(0ミリ秒コールドスタート)

少しだけしくみにも触れておきます。 Workers基盤上では、V8 EngineのIsolateが利用されており、リクエストごとに軽量かつ独立した環境でユーザーコードが実行されます。 さらに、TLSハンドシェイク中にWarmupを終わらせることで、0ミリ秒コールドスタートを実現しています。これらの発明が従来のFaaSのコールドスタート問題を解決したおかげで、用途が格段に広がったのだと思います。 開発者体験の面では、デフォルトではWorkers専用ドメイン(workers.dev)で動くため独自ドメイン追加することなく始められますし、専用のCLIツールがシンプルで使いやすいです。CI/CDは公式のGitHub Actionで簡単にセットアップできます。また、HonoというWebフレームワークを使うとより開発が楽になるのでお勧めです。 そのほかのサービスも一部概要を紹介します(すべてのサービスとその詳細はこちらを参照してください)。次のようなサービスをCloudflare Workersと組み合わせることで、さらに多様なアプリケーションが構築できるようになります。Edge Server上で処理を完結させられれば、より早くレスポンスを返すことができ、ユーザー体験の向上につながるでしょう。

  • Cloudflare Pages: Gitと統合されたJAMstackプラットフォーム
  • Cloudflare D1: SQLiteベースのデータベース
  • Cloudflare R2: S3互換でエグレス料金無料のオブジェクトストレージ
  • Cloudflare Workers KV: key-valueデータストレージ
  • Cloudflare Queues: メッセージキュー

運用上の課題としては、まだIAM(Identity and Access Management)に相当する機能がないため、最小の権限でのワークロード実行制御ができません。たとえば、「特定のCloudflare WorkersからはCloudflare R2の読み取りだけしかできない」といった制御です。一方「特定のCloudflare Workersから特定のCloudflare R2のすべての操作」はBindingによる紐づけを前提としており、制御できるようになっています。 ユーザーアカウントに関しては、RBAC機能を利用してある程度権限が管理できますが、リリース環境ごとに権限を分離するなどの制御はできません。とはいえ、IaCを前提としたGitリポジトリ側での統制により、ある程度担保できるでしょう。また、管理コストは上がりますが、本番環境とその他の環境をアカウント(テナント)やドメイン単位で分離することも有効な手段です。

Cloudflare Registrar

Cloudflare Registrarは、Cloudflareが運営するレジストラです。ほかのレジストラと比較して特別な機能があるわけではないですが、レジストリやICANNの請求される費用(つまり原価)のみで利用できるのが魅力です。すでにCloudflareを使っていれば、集約による管理コストの低減が期待できるでしょう。Google Domainsの売却の発表に伴い、その移行先としても注目を集めています。Cloudflare DNSと同様にCloudflare CDNを使うための必須条件ではありません。

Cloudflare Waiting Room

Cloudflare Waiting Roomは仮想待合室サービスです。想定したキャパシティを超えた急激なトラフィックの上昇からWebアプリケーションを守り、一定の可用性を維持できます。数百の自治体の新型コロナワクチン予約サイトで導入されていました。 利用するための前提条件は、Cloudflare CDNが設定済みでCookieが有効になっていることです。あとは対象のホストやパス、閾値などを設定するだけでWaiting Roomを適用できます。トラフィックが設定された閾値を超えたときユーザーは待合室に誘導されます。待合室入ったユーザーには待合室専用のページが表示され、20秒ごとに推定待ち時間が更新されます。その後、デフォルトではFirst In First Out(FIFO)でOrigin Serverへ到達できるようになります。

IaC

キャディでは、Cloudflareに関してもともとIaC管理できていませんでしたが、履歴管理や変更容易性などの観点から徐々にIaC化を進めています。とくにCloudflare DNSやCloudflare Accessは、変更頻度が比較的高く、変更履歴や監査ログも重要ですので、早めにIaC化して良かったと感じています。まだIaC化はこれからという方は、公式のTerraformベストプラクティスを参考にして進めるとよいでしょう。

Enterprise Plan

低コストでさまざまなサービスを利用できるのは、Cloudflareの大きな魅力です。しかし、組織としてさらに統制を効かせやすくしながらプロダクトの運用レベルを上げるためには、Enterprise Planへの移行が必要になります。一例ですが次の機能はEnterprise Planでしか利用できません。

  • Cloudflare DashboardのSSO対応
  • ホスト単位のキャッシュパージ
  • Request Log(Access Log)のExport
  • Audit LogのExport

また、Enterprise Planの顧客専用のチームがサポートチケットに対応してくれるため、回答の質やスピードが向上します。2 ちなみに、RBAC機能は以前はEnterprise Plan限定でしたが、2023年にほかのプランにも解放されました。

連載のおわりに

今回が本連載の最終回となります。2021年7月に2名で立ち上げたPlatform Teamですが、2年数ヵ月経過した現在、メンバーが大幅に増えPlatform Groupになりました。本連載では、筆者らがその間に取り組んできたことの一部を紹介してきました。 振り返ってみると、筆者らが本連載の企画を始めたとき、まだPlatform Engineeringという言葉はそれほど認知されていませんでした。そのため、議論の結果「Google Cloudで実践するSREプラクティス」というタイトルや内容に落ち着いたと記憶しています。ところが、Gartnerのテクノロジートレンドに登場したり、Platform Engineering Meetupが盛り上がっていたりと、現在はだいぶ認知が進んできたようです。今後も機会があれば、筆者らの取り組みをなんらかの形で共有したいと思います。 本連載が、みなさんにとって価値のあるDevOps、SREを実現するためのヒントになっていたら幸いです。最後までお読みいただきありがとうございました。

  1. 一部内容に誤りがあったため、訂正してあります。↩
  2. キャディでは、Cloudflare Accessの不具合を報告し、修正してもらったことがあります。↩