Merge pull request #1272 from future-architect/feature

Cloudflare

source/_posts/20240527a_Cloudflare連載を始めます_&_WorkersにPythonをデプロイして動かしてみる.md

@@ -41,7 +41,7 @@ AWSなどのパブリッククラウドではリージョン、ゾーンとい
 | ---- | ----- | ---------- |
 | 5/27 | 伊藤太斉 | WorkersにPythonをデプロイして動かしてみる |
 | 5/28 | 真野隼記 | [Cloudflare D1 を触ってみる](/articles/20240528a/) |
-| 5/29 | 宮崎将太 | Cloudflareにおけるアーキテクチャ選定 |
+| 5/29 | 宮崎将太 | [Cloudflare採用のアーキテクチャ選定](/articles/20240529a/) |
 | 5/30 | 大岩潤矢 | Cloudflare R2とNextCloudで自分だけのクラウドストレージを作ろう |
 | 5/31 | 小林弘樹 | Webサイトのメンテナンスイン/アウトを実装 |
 

source/_posts/20240529a_Cloudflare採用のアーキテクチャ選定.md

@@ -0,0 +1,135 @@
+---
+title: "Cloudflare採用のアーキテクチャ選定"
+date: 2024/05/29 00:00:00
+postid: a
+tag:
+  - Cloudflare
+  - アーキテクチャ
+  - CDN
+  - WAF
+category:
+  - Infrastructure
+thumbnail: /images/20240529a/thumbnail.png
+author: shotap
+lede: "![image.png]"
+---
+
+<img src="/images/20240529a/image.png" alt="" width="1200" height="404" loading="lazy">
+
+[Cloudflare連載](/articles/20240527a/)3日目の記事です。
+
+## はじめに
+
+こんにちは、TIGの宮崎将太です。  
+
+これまで個人/業務ともにあまりCloudflareを使用してきませんでした。クラウド前提で仕事をしていると、各クラウドプロバイダーが提供するCDNやWAFがあり、その部分だけ外部サービスを採用するメリットを見いだせなかったことが最大の理由です。
+
+しかし、とある事情からCloudflare採用に至るケースが発生したので、その動機と比較検討内容を記事にしておこうと思います。
+
+## どんなアーキテクチャでCloudflareを採用したのか？  
+
+結論ですが、ハイブリッドクラウド構成でのCDN/WAFとしてCloudflareを採用しました。  
+
+構成は少しぼかしますが、メインのサービス提供はAWS、認証機能の提供のみAzureを使用しています。想定するユースケースにおいてコストメリットもあるため基本的なクラウド環境にはAWSを使用しているのですが、ある特定のケースでは認証領域においてAzureの方が機能的/コスト的優位であり、ハイブリッド構成を取っています。  
+
+Cloudflareに期待する役割はCDN、WAF（ついでにDNS）であり、各サービスへのゲートウェイとして機能しています。  
+
+<img src="/images/20240529a/c0453d5e-005e-585d-29ef-99f8ced603fd.png" alt="" width="1200" height="499" loading="lazy">
+
+## 取りうるアーキテクチャの比較
+
+さて、これだけ見るといろいろと突っ込みどころがあるかと思います。  
+
+前提として、Azureの認証サービス側はWAF機能を賄ってくれなく、別途WAFと連携する必要があります。  
+
+もちろん、だとしてもやたらと採用サービスを増やすのは得策ではなく、各クラウドサービスで対応できるのであれば当然そちらの方がベターです。  
+
+CDN、WAF、DNSはAWS/Azure単体でカバーすることもできるので、考えられる以下3案をを比較してみます。  
+
+1. AWSとAzureをそれぞれ独立させて管理する
+2. AWSかAzureをゲートウェイとし、もう片方のクラウドにルーティングさせる
+3. Cloudflareをゲートウェイとし、それぞれのクラウドにルーティングさせる  
+  - 別サービスとしては当社にて採用実績のあるCloudflareとAkamaiを比較しましたが、Akamaiはコスト面で圧倒的に劣る（その分機能は豊富ですが）ので今回の比較からは除外します。  
+
+比較の前提として、CDN/WAFには以下の要素を求めます。
+
+- IP制限、リージョン制限等の一般的なアクセス制限機能
+- WAF保護ルールの継続的なアップデート
+- ※その他機能はあれば尚良しで加点
+
+上記を前提とした場合それぞれのクラウドでの採用サービス候補は以下とし、参考のため基本的な料金を載せておきます。
+
+- AWS: CloudFront + AWS WAF
+  - CloudFront 基本料金: なし,  データ転送料(エッジ): 10TBまで0.114USD/月, データ転送料(オリジン): 0.060USD月, リクエスト料: 0.009USD/月
+  - AWS WAF 基本料金: なし, Web ACL: 5USD/月, ルール1件あたり: 1USD/月, リクエスト100万件あたり: USD 0.6USD/月, マネージドルール: ものにより5USD~30USD/月程度
+    - マネージドルールの利用料にも寄りますが、100USD/月程度と過程します。  
+- Azure: AzureFrontDoor Premium
+  - 基本料金: 330USD/月、データ転送量: 0.115USD/GB (エッジからクライアント) 0.06USD/GB (エッジから配信元)
+- Cloudflare: Cloudflare Businessプラン
+  - 料金: 250USD/月, データ量による従量課金: なし
+
+### ①AWSとAzureをそれぞれ独立させて管理する  
+
+<img src="/images/20240529a/709b68d9-ec9a-4772-3e99-028227cfc9d1.png" alt="" width="922" height="538" loading="lazy">
+
+
+AWSではCloudFront/AWS WAF、AzureではAzureFrontDoorを採用し、それぞれ独立したシステムとするパターンです。  
+まずはこのパターンを考えたくなると思います。  
+
+他パターンと比較すると可用性ではAWS/Azureで独立しているので、何かしら障害が起きた場合でも相互に影響することはなく、余計な心配をする必要はありません。  
+
+ただし、同じCDN/WAFという機能にそれぞれコストを支払うことになるのと、機能的にもルールのメンテナンスに不安が残るのが痛いところ。  ルールメンテナンスにWAFCharmなど外部サービスを組み合わせる手もありますが、その場合はAWS/Azureで2つライセンスが必要になるので、更にコストがかさみます。（WAFCharmは2023年の料金改定で1ライセンスあたり十数万/月となりました。)
+
+また、メンテナンスイン/アウトなどをCDNレイヤで実施する場合はAWS/Azureそれぞれで操作が必要になり、管理が煩雑になりがちです。  
+
+### ②AWSかAzureをゲートウェイとし、もう片方のクラウドにルーティングさせる  
+
+<img src="/images/20240529a/eaa742af-4d9b-05f2-7afe-26d3cea905f0.png" alt="" width="1200" height="489" loading="lazy">
+
+①を考えた時に、CDN/WAFのコスト/運用を圧縮しようと思うと片方のクラウドをゲートウェイ化する案も考えられます。
+
+一見あり得る構成かと思ましたが、実際に検証をしてみたところ、少なくともCloudFrontからAzure認証サービスへのルーティングはAzure側がエラーステータスを返却してしまい、テクニカルサポートに相談をしても他クラウドプロバイダーとの連携はサポート外と言われてしまいました。（これ自体は言われてみれば当然かと思います。）  
+
+仮に一時的に問題が解決したとしても継続的なサービス提供には不安が残るため、採用は見送りました。もちろん採用サービスによっては技術的制約が無い場合はあり、そのケースではこちらの案も取り得るかと思います。  
+
+ただし、その場合でも①同様WAFルールセットの更新に不安は残り、外部サービスで補強しようとすると結局③の方が安価になる可能性はあります。  
+
+### ③Cloudflareをゲートウェイとし、それぞれのクラウドにルーティングさせる
+
+<img src="/images/20240529a/03bf4522-e2c8-0868-f056-1e8d077d298c.png" alt="" width="1200" height="478" loading="lazy">
+
+最後に件のCloudflareをゲートウェイとするパターンです。  
+
+CloudflareのWAFはCloudflare社が管理するマネージドルールの定期的なアップデートがある他、機械学習によって自動的にルールのアップデートがなされます。  
+
+また、ゼロトラストやCloudflare Workersなどの機能もあり、CDN/WAF/エッジとしての機能は比較的豊富です。ハイブリッドクラウド構成の場合はドメインを一箇所で管理できるメリットもあります。  
+
+Cloudfront/AWS WAFと比較すると多少値が張りますが、構成によってはクラウドプロバイダーそれぞれでコストを支払うよりも安上がりになります。  
+
+また、BusinessプランではSLA100%であり、この構成にした事による可用性減は発生しません。
+
+### まとめ
+
+比較検討表を記載します。  
+
+③のパターンではCloudflare以外にも候補がある可能性はありえますが、各クラウドプロバイダーとの連携がサポートされている点は大きく評価できるかと思います。  
+
+表には記載していませんが、GoogleCloudとの連携もサポートされており、様々なケースの使用が期待できそうです。
+
+|  | AWSとAzureをそれぞれ独立させて管理する | AWSかAzureをゲートウェイとし、もう片方のクラウドにルーティングさせる | Cloudflareをゲートウェイとし、それぞれのクラウドにルーティングさせる |
+| - | - | - | - |
+| 概要 | AWSではCloudFront/AWS WAF、AzureではAzureFrontDoorを採用し、それぞれ独立したシステムとする。 | 例えばCloudFrontのオリジンとしてAzureを登録する。<br>もしくはAzureFrontDoorの配信元としてAWSを登録する。 | CloudflareをCDN/WAFとして使用し、AWS/Azureにルーティングさせる。<br> |
+| 機能 | △<br>CloudFront/AzureFrontDoorともにマネージドルールのアップデートはあるものの、頻度に不安があり、しばしばWAFCharmなどでルールセット更新を自動化することがある。 | △<br>AWSとAzureをそれぞれ独立させて管理するパターンと同等。 | ◯<br>Cloudflareが管理するルールによって、先進のゼロデイ脆弱性保護が得られる。<br>また、WAF機械学習によりルールセットが補完される。<br>リスト型攻撃のチェックによりアカウント乗っ取りを監視/ブロックする。<br>その他ゼロトラストやCloudflare Workersなどの機能もあり、CDN/WAF/エッジとしての機能は比較的豊富。<br>ドメインを一箇所で管理できるメリットもある。 |
+| 可用性 | ◯<br>AWS/Azureで独立しているので、何かしら障害が起きた場合でも相互に影響することはない。 | △<br>ゲートウェイとなっているサービスに障害が発生すると<br>もう片方のサービスにもアクセスできなくなってしまうので、①と比較すると可用性は落ちる。<br>※CloudFrontは99.9%のSLAを維持する努力をするとあるが、保証するものではない。<br>    AzureFrontDoorは99.99%のSLAが保証されている。 | ◯<br>Cloudflare BusinessプランであればSLA100%が保証されるので、<br>この構成を取った事による可用性ダウンはなし。 |
+| コスト | △<br>AWS/AzureそれぞれでCDN/WAF料金を支払うことになるので、その分コスト増になる。<br> | ◯<br>AWS/Azureどちらかにコストを集約することができる。<br> | ◯<br>Cloudflareにコストを集約することができる。<br>BusinessプランではAWS/Azure併用よりも安価である。 |
+| 運用 | △<br>例えばメンテナンスイン/アウトさせる場合、それぞれのクラウドでオペレーションが必要であり、運用保守者からすると習熟コストが高い。 | ◯<br>AWS/Azureどちらかに運用を集約することができる。 | ◯<br>Cloudflare自体の習熟は必要となるが、運用作業自体はCloudflareに集約することができる。<br>また、CDN/WAFとしてのCloudflareは比較的習得し易い仕様である。 |
+| 技術的制約/サポート | ◯<br>AWS/Azureで独立しているので、構築の上での技術的制約は無い。<br>テクニカルサポートに回答を断られることはない。 | △<br>検証した限りではCloudFrontのオリジンとしてAzure認証サービスを登録した場合、Azure側でエラーが発生してしまい回避させることが不可であった。<br>他クラウドとの連携ということもあり、トラブルに際する問い合わせもたらい回しにされがち。 | ◯<br>Cloudflareが各クラウドプロバイダーとの連携を案内しており、技術的な制約はなし。<br>https://www.cloudflare.com/ja-jp/multi-cloud/aws/<br>https://www.cloudflare.com/ja-jp/multi-cloud/azure/<br>またクラウドプロバイダー側もCloudflareを連携パートナーとして案内している。 |
+| 総評 | コストと運用がネック。<br>また、WAFルールセットの更新に不安が残る。 | 採用サービスによっては技術的制約が無い場合があり、そのケースでは採用し得る。<br>WAFルールセットの更新頻度には不安が残る。 | コストメリットが高く、ハイブリッドクラウド構成では十分に採用し得る。 |
+
+## 最後に
+
+クラウド化が進む昨今ですが、徐々にそれぞれのクラウドプロバイダーに得意/不得意が見えてきています。
+
+もちろん各プロバイダーは不得意を補う動きもするでしょうが、ITサービスの対応領域が拡大する昨今、基本的には強みを伸ばしていく戦略を取るのではないでしょうか。  
+
+そうなった場合、Cloudflareのような領域特化のクラウドサービスを組み合わせていくことも増えていくかと思いますので、同じような検討をする方の参考になれば幸いです。