Recommended
More Related Content
What's hot
What's hot (20)
Similar to 動的コンテンツをオリジンとしたCloudFrontを構築してみた
Similar to 動的コンテンツをオリジンとしたCloudFrontを構築してみた (20)
動的コンテンツをオリジンとしたCloudFrontを構築してみた
- 2. 自己紹介 • かわむら たいき 30さい ♂ • 前職：バックエンド実装、環境構築 • 現職：インフラ全般 • (開発的な)趣味：シェルスクリプトによる自動化 、シェルスクリプトによるログ調査
- 3. あらすじ • CDNであるCloudFrontをAPIサーバのフロントエ ンドにおいたよ • なぜそんなことを？ • 気をつけること • キャッシュとか
- 4. CloudFrontって？ • グローバルコンテンツ配信ネットワーク(CDN) • 静的コンテンツ高速配信 • アタックに対する防御
- 5. CloudFront導入のメリット • 通信の高速化 • ELBに直接アクセスするより速い(参考： https://www.slideshare.net/AmazonWebServices/secured-api-acceleration- with-engineers-from-amazon-cloudfront-and-slack/11) • CloudFront Latency Based Routing • TCP/IP Optimizations for the Network Path • Keep-Alive Connections to reduce RTT • AWS Backbone Network • SSL/TLS Optimizations
- 6. CloudFront導入のメリット • プログラムを極力いじらずに・・・ • 将来的にキャッシュさせるコンテンツはキャッシュさせたい • WAFに対応 • 特定のルールでのアクセスを弾きたかった • ex) http://hogehoge.com/phpMyAdmin/… • プログラムの変更があれば・・・ • 署名付きURLに対応
- 7. 従来
- 8. こうしました
- 12. 気をつけること ハマったこと • エラー発生時、CloudFrontのエラーログを見ることがで きない • 画面に「CloudFrontのエラー」「リクエストID： XXXXXXしか出ない」 • スクショ送られると・・・ • サポートにスクショをそのまま送る • 自分で文字起こす
- 13. 気をつけること ハマったこと • アクセスログが1ディレクトリ • Athenaが辛い・・・ • ELBのアクセスログのように適当にディレクト リを切ってくれれば・・・ • lambdaかなにかで定期的にディレクトリ作成、 ファイル移動するものを自作せよとのお達し
- 15. まとめ • 動的コンテンツにCloudFrontを使ってみました • プログラムの変更はほぼなく利用できました • 注意する点はいくつかあります
- 16. • ご清聴ありがとうございました
Editor's Notes
- それでは、ELBをオリジンとしたCloudFrontを構築してみた、という内容をお話してまいりたいと思います。
- まず自己紹介から かわむらたいき30歳オス まぁ見たまんまですかね。 前職では新卒入社し、LAMP環境構築してAPI作成や管理画面作成をしていました。 現職では前職おざなり？になっていたインフラを鍛えようと思いインフラを中心に仕事させてもらってます。 通常の趣味はいっぱいあるので割愛して開発的な趣味を話すと、シェルスクリプトによる自動化とシェルスクリプトによるログ調査を嗜んでいます。awkとかsedとかgrepとかですね。 ここまで聞くとただの変態ですが、普通の趣味もいっぱいあります。
- では、本題に戻りまして、今日お話する内容をサクッと 簡単です。やったことと、なぜやったかと、どうやったかです。加えて、気をつけること、という内容です。
- ではまず、もしかしたらCloudFrontのことをご存じない方もいらっしゃるかもしれませんので CloudFrontの簡単な内容を説明させていただきます。 CloudFrontはグローバルコンテンツ配信ネットワーク、通称CDNと言われるもので、AWSのマネージドサービスとして提供されているものです。 もっと砕くと、画像やら動画やらの(いかがわしくない方の)静的コンテンツ、staticコンテンツをエッジサーバにキャッシュすることで、オリジンサーバ、元々画像をおいているサーバへのアクセスを減らし、高速にコンテンツを配信するものとなっております。 それに加えてAWSではWAFという機能がありまして、特定のルールを設定するとそのアクセスだけ通したり拒否したりをできるものなのですが、それとCloudFrontを組み込ませることができるので、それを目的に導入することもあるのではないかなと思っています。 本日は、このCloudFrontを画像配信のためではなく、APIのフロントとしておいた、という話を今日はします。おいおい、ちょっと前に静的コンテンツをキャッシュするって言ったじゃないか、APIのような動的コンテンツをキャッシュしたら某フリマアプリみたいに別の人の情報でちゃうんじゃないの？という疑問をお持ちの皆様に対する回答を今日のキモとしてお話させていただきます。 なぜまたキャッシュさせないAPIにCloudFrontをかませる必要が？ということになりますが、メリットはいくつかあります。
- まずはこちら。 通信の高速化が見込まれます。 直接ELBにアクセスしたほうが速いんじゃないか？と普通ならば思うところですが、同じくAPIの通信も全てCloudFront経由にしたSlackさん調査によりますと、CloudFrontを経由したときのほうがルーティングや設定が最適化されており、レイテンシが小さくなるそうです。
- 次にこちらです。 CloudFrontに限らず、新しく導入するときに問題になってる方もいらっしゃるかと思うのですが、新規に何か導入する際にAPI作成担当者に変更をお願いする必要があるのだけども、他の施策等が優先されがち、というケースがあるかと思います。 そんな中でもCloudFrontはプログラムの変更をすることなくキャッシュの設定やWebApplicationFirewallを設定することができます。 例えばよくみるアタックの一つのphpMyAdminに関するアクセスをCloudFront側で弾いてしまうことによって、不要なアクセスをAPIサーバに渡さないようにしています。 プログラムの変更があれば、署名付きURLに対応することもできます。
- システムどうしたか、を一応図的にお話させていただきます。 図にするほどの説明でもないと思ってはいますが。 従来ではよくありがちなELBの下にAPIサーバがぶら下がっている構成にしておりました。 変更後もこれは変わらないのですが。
- 変更後はこうなっております。 ELBの前に、CloudFrontを噛ましているような形ですね。 本当に図が必要だったのかというくらいの内容だと思います。 Slackさんの調査では、ELBに直接アクセスするよりCloudFrontを経由したほうが速かったとの、直感的にはびっくりな結果が出たそうです。どれくらい涙ぐましいチューニングがなされているのか、時間があったら調べてみたいなと思いました。 つまりまだしてないということです
- つぎにどう設定したかをお話します。 とはいえ全部ではなく、オリジンがAPIのときのCloudFrontの設定のときに注目すべきポイントです。 まず、Forward HeadersをAllにします。これ以外の方法もあるにはあるっぽいのですが、ひとまず安全にすべての通信をオリジンに問い合わせてほしいので弊社ではこうしました。他にはWhiteList、Noneが選べます。そうすると下の項目のObject Cachingが利用できるようになり、OriginのCache-Controllヘッダの中身を見てCloudFrontにキャッシュをさせるか、それを無視してカスタマイズでキャッシュさせるかを選ぶことができます。 Cookieも相手がAPIサーバなので転送してあげます。 S3がオリジンの場合はNoneにするとよいそうです。 クエリ文字列も全て転送してあげましょう。 クエリ文字列にかかわらず同じものを返すときには違う設定にすると良いそうです。
- 次から、気をつけることやハマったことについて話していこうと思います。 まずはじめですが、ELBにもSSLの設定が要ります、ということです。 なんだ当たり前じゃないか、と思われる方もいらっしゃるかと思いますが、コンソールでポチポチしていると、ついELBにインスタンスを釣っている感覚になってしまって、検証環境でCloudFrontの方のSSLを更新したのにELBのSSLの更新を忘れて通信できなくなった、ということがあります。
- 次ですが、CloudFrontからオリジンへの実行タイムアウトがAWS側で決められており、それが30秒ということです。 ですので、とても長い実行時間の画面があるサービスには導入に注意したほうがいいです。 これは設定などすることができず、30秒決め打ちされています。
- 次ですが、ちょっと前のスライドに関連してまして、とあるときに実装/検証担当者から「こんなエラーが出たんだけど」ってスクショをもらいました。みると「CloudFrontのエラー」「リクエストIDズラズラズラ〜」っていう情報だけなんですね。 もちろんこれだけではわからないので調べてみようと思ったのですが、エラーログみたいなのがないのです。 なので、問い合わせるしかなく、サポートにそのままスクショを送るか・・・優しい人は自分で文字起こして送るという手段でしかわかりません。ちなみに、そんな風に送ったら「タイム・アウトしてますね」と回答が帰ってきて、前のスライドの内容になります。
- 次ですが、アクセスログが1ディレクトリにバリバリ吐かれることです。 ELBの場合はよしなに年月日でディレクトリを切ってくれるのですが、CloudFrontでは気の利いたことをしてくれないようです。ELB担当者を見習ってほしいです。 これのせいで、Athenaで日ごとにテーブル作ってアクセス解析、に一手間かけることになります。 ちなみに「なんとかならんのですか？」と問い合わせたところ、ラムダかなにかでやって、とのお達しでした
- つぎですが、よくミドルウェアやアプリケーションでアクセス元IPアドレスで動作を変えていることがあるかと思います。CloudFrontを挟むと、X-Forwarded-Forにカンマ区切りでIPアドレスが追記されるので、それをうまく処理できるようにしないと「IPが一致しない！」みたいなことになってアクセスできないみたいなことになるかもしれません。
- まとめです 動的コンテンツにCloudFrontを使ってみました プログラムの変更はほぼなく利用できましたので、割と喜ばれました 注意する点はいくつかありますので、今日のことが皆様の参考になることがあれば幸いです。