AWSが公表している 「BestPractices For Wordpress on AWS」AWS CDK で作ってみた

近い内に、CDKのコードもGithubのパブリックリポジトリにアップします。

Transcript

1. AWSが公表している 「BestPractices For Wordpress on AWS」 AWS CDK で作ってみた
2. 自己紹介 会社名: 株式会社シーエー・アドバンス 名前：金城 裕也(きんじょう ゆうや) kinjou_yuya@ca-adv.co.jp github.com/yuyakinjo 最近、CDKやってます
3. 今日話したい事 ・ベストプラクティスで公開されているアーキテクチャを参考にCDKで作ってみた ・当初やろうとしていた構成 VS ベストプラクティスでパフォーマンス比較 ・ベストプラクティス + α ・やってみて感想
4. AWS CDKとは
5. AWS CDK とは ・AWS Cloud Development Kit（CDK）は、クラウドインフラをコード で定義するためのオープンソースのソフトウェア開発フレームワーク です ・Python, Java, TypeScript等の言語を使えます ・CloudFomation −（JSON・YAMLつらみ） = CDK
6. 「BestPractice For Wordpress on AWS」を取り入れるまでの背景
7. 弊社でグループ会社の社内・社外広報 サイトを担当 ・非エンジニアさんでもサイト編集できるよう広く普及した wordpress採用
8. 現状の構成(グレーアウトは非採用)
9. 課題点 ・サイトちょっと重いね（特に初期表示・画像・動画） ・アクセス殺到すると落ちるね（DBコネクション原因ぽいね） ・データ料金（EFS）高いね
10. 改善アクション ・サイトちょっと重いね（特に初期表示・画像・動画） → CloudFrontでキャシュ ・アクセス殺到すると落ちるね（DBコネクションプール枯渇が原因ぽい） → AuroraServelessV2に切り替え ・データ料金（EFS）高いね → S3に画像・動画移動
11. でも実は、AWSの担当者様から アドバイスはもらっていた・・・ 弊社では、年1ぐらいで（コロナ時期除く）、AWSの担当者様から 新しいサービスの紹介や、現在弊社で運用しているシステムの アーキテクチャを直々にレビューしてもらう機会がありました。 その時に、上述した課題点をお伝えし、ベストプラクティスなるものを共 有してもらっていた。
12. 「Best Practices for WordPress on AWS」 の概要
13. ・AWS ホワイトペーパーとガイド AWS と AWS コミュニティによって作成された、テクニカ ルホワイトペーパー、技術ガイド、参考資料、リファレンス アーキテクチャ図などの技術文書(抜粋)。 Best Practices for WordPress on AWS
14. ベストプラクティス構成
15. 現状の構成(グレーアウトは非採用)
16. 改善アクション → CloudFrontでキャシュ → AuroraServelessV2に切り替え → S3に画像・動画移動 → 上記で、課題は解決するはずだから、 memcachedはオプションで！！
17. memcachedなしでいくぞう
18. CDKにて作成後、パフォーマンス比較
19. 負荷テストで、1200req / 10sec 結果：2xx → 20%弱 リクエスト過多 → ALB 503 もしかして、memcached必 要なのか 伸びない・・・
20. memcached追加！！
21. アクセス改善1000倍以上 248req/10sec → 20000req/10sec ※リンクを共有して10秒以内に全社員がアクセスしたのを想定
22. 負荷テストで、20000req / 10sec 結果：2xx → 99%以上 リクエスト過多 → ALB 503 ならない memcached必要やん！ 伸びすぎた草
23. ELB が503返さない memcached 必要やん！
24. レスポンスタイム改 善 memcached 必要やん！
25. DBコネクション枯 渇しない memcached 必要やん！
26. ECSのメトリクスが穏やかになっている スパイクしても、スケールする余裕ある。。。
27. memcached 頑張ってるね
28. ・memcached ・memcachedを活かすplugin(w3-total-cache) ・pluginの使用方法もリポジトリで解説してました まとめ：強さのポイント
29. ベストプラクティス + α
30. EC2のスケール管理辛い + そういえば、 認証必要だった
31. ・スケール管理を楽にしよう EC2 → ECS ・認証 社内向けのためコンテンツ・コンテンツに掲載されている画像・動画類 → 社内のSSO通った人のみ ベストプラクティス ＋ α
32. 構成図でみる認証経路
33. ・①⇔④ CloudFront - ALB 間はOIDC使う（やったことある） ・①⇔② CloudFront - S3間どうしよう（やったことない） 認証は、社内独自SSO(CASSO)
34. え、Lambda@EdgeとCognito 準備するの・・・ Lambda + Cognito大げさ・・・ 公式見ると実装例ある！が・・・・
35. 世にあるのもそ れに追随する が多い・・
36. ALB ⇔ S3 に認証を寄せるか 副作用：CloudFrontのキャッシュ使わないことになるかもだけど。安全第一 参考例あるかな・・・・ 近いのあった！！！！ リリースが昨年末 1. VPC Endpointを準備 2. ALBのターゲットグループに設定 これこれ感
37. 認証込み構成図
38. ・EC2 → ECS Fargate ・認証 ALB ⇔ VPC Endpoint ⇔S3 1. すべての認証経路をALBのOIDCに寄せ、サーバーサイドに リクエストが届かない(便利！) 2. アプリ側で認証を実装しない(差分少なくて楽！) +α の まとめ
39. 今回やってみた感想
40. ベストプラクティス は 裏切らない
41. ・認証はさんだ時のキャッシュ(CloudFront)の扱い方 headerとかcookieとかの条件が難しいのでパス！安全第一 苦労したところ①
42. ・CDKでVPC EndpointのENIからPrivate IPアドレスの取得 まだ普及していないやり方なので、CDKではまだ実装 例ないので、自力で取得！ 参考 ：https://aws.amazon.com/jp/blogs/networking-and-content-delivery/hosting-internal-https-static-websites-with -alb-s3-and-privatelink/ 苦労したところ②
43. 流れ VPC Endpoint作成 ↓ ENIからIPアドレス抽出 ↓ ALBのターゲットグループ に追加
44. 次の改善点
45. 次の改善点 ・CloudFront入れたけど、まだキャッシュさせてるものない（副作用） → ホワイトペーパーにヒントがありそう ・ALB ⇔VPC Endpoint ⇔ S3間のキャッシュ → AWS File CacheかAWS StorageGateway使えそう？ ・誰でも使えるようにしたい → ConstructHub、Github、Qiita等で共有
46. 現場からは以上です。