Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AWSが公表している 「BestPractices For Wordpress on AWS」...
Search
kinjo
June 29, 2023
Programming
0
1k
AWSが公表している 「BestPractices For Wordpress on AWS」AWS CDK で作ってみた
近い内に、CDKのコードもGithubのパブリックリポジトリにアップします。
kinjo
June 29, 2023
Tweet
Share
More Decks by kinjo
See All by kinjo
初めてAWSサミット行ってきた
kinjo_yuya
0
23
Other Decks in Programming
See All in Programming
実践!難読化ガイド
mitchan
0
120
Rubyとクリエイティブコーディングの輪の広がり / The Growing Circle of Ruby and Creative Coding
chobishiba
1
260
Prolog入門
qnighy
4
990
状態管理ライブラリZustandの導入から運用まで
k1tikurisu
3
460
Rubyのobject_id
qnighy
6
1.3k
[DroidKaigi 2024] Android ViewからJetpack Composeへ 〜Jetpack Compose移行のすゝめ〜 / From Android View to Jetpack Compose: A Guide to Migration
syarihu
1
260
Lessons by WebAssembly app in production on CDN Edge Computing Service
tetsuharuohzeki
0
170
ドメイン駆動設計を実践するために必要なもの
bikisuke
3
330
『ドメイン駆動設計をはじめよう』中核の業務領域
masuda220
PRO
5
970
What we keep in mind when migrating from Serverless Framework to AWS CDK and AWS SAM
kasacchiful
1
140
LangChainの現在とv0.3にむけて
os1ma
4
840
connect-go で面倒くささと戦う / 2024-08-27 #newmo_layerx_go
izumin5210
2
630
Featured
See All Featured
It's Worth the Effort
3n
182
27k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
8.9k
Fashionably flexible responsive web design (full day workshop)
malarkey
401
65k
Robots, Beer and Maslow
schacon
PRO
157
8.1k
Bootstrapping a Software Product
garrettdimon
PRO
304
110k
Learning to Love Humans: Emotional Interface Design
aarron
270
40k
Faster Mobile Websites
deanohume
304
30k
Visualization
eitanlees
142
15k
Become a Pro
speakerdeck
PRO
22
4.9k
What’s in a name? Adding method to the madness
productmarketing
PRO
21
3k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
24
600
Rails Girls Zürich Keynote
gr2m
93
13k
Transcript
AWSが公表している 「BestPractices For Wordpress on AWS」 AWS CDK で作ってみた
自己紹介 会社名: 株式会社シーエー・アドバンス 名前:金城 裕也(きんじょう ゆうや)
[email protected]
github.com/yuyakinjo 最近、CDKやってます
今日話したい事 ・ベストプラクティスで公開されているアーキテクチャを参考にCDKで作ってみた ・当初やろうとしていた構成 VS ベストプラクティスでパフォーマンス比較 ・ベストプラクティス + α ・やってみて感想
AWS CDKとは
AWS CDK とは ・AWS Cloud Development Kit(CDK)は、クラウドインフラをコード で定義するためのオープンソースのソフトウェア開発フレームワーク です ・Python,
Java, TypeScript等の言語を使えます ・CloudFomation −(JSON・YAMLつらみ) = CDK
「BestPractice For Wordpress on AWS」を取り入れるまでの背景
弊社でグループ会社の社内・社外広報 サイトを担当 ・非エンジニアさんでもサイト編集できるよう広く普及した wordpress採用
現状の構成(グレーアウトは非採用)
課題点 ・サイトちょっと重いね(特に初期表示・画像・動画) ・アクセス殺到すると落ちるね(DBコネクション原因ぽいね) ・データ料金(EFS)高いね
改善アクション ・サイトちょっと重いね(特に初期表示・画像・動画) → CloudFrontでキャシュ ・アクセス殺到すると落ちるね(DBコネクションプール枯渇が原因ぽい) → AuroraServelessV2に切り替え ・データ料金(EFS)高いね → S3に画像・動画移動
でも実は、AWSの担当者様から アドバイスはもらっていた・・・ 弊社では、年1ぐらいで(コロナ時期除く)、AWSの担当者様から 新しいサービスの紹介や、現在弊社で運用しているシステムの アーキテクチャを直々にレビューしてもらう機会がありました。 その時に、上述した課題点をお伝えし、ベストプラクティスなるものを共 有してもらっていた。
「Best Practices for WordPress on AWS」 の概要
・AWS ホワイトペーパーとガイド AWS と AWS コミュニティによって作成された、テクニカ ルホワイトペーパー、技術ガイド、参考資料、リファレンス アーキテクチャ図などの技術文書(抜粋)。 Best Practices
for WordPress on AWS
ベストプラクティス構成
現状の構成(グレーアウトは非採用)
改善アクション → CloudFrontでキャシュ → AuroraServelessV2に切り替え → S3に画像・動画移動 → 上記で、課題は解決するはずだから、 memcachedはオプションで!!
memcachedなしでいくぞう
CDKにて作成後、パフォーマンス比較
負荷テストで、1200req / 10sec 結果:2xx → 20%弱 リクエスト過多 → ALB 503
もしかして、memcached必 要なのか 伸びない・・・
memcached追加!!
アクセス改善1000倍以上 248req/10sec → 20000req/10sec ※リンクを共有して10秒以内に全社員がアクセスしたのを想定
負荷テストで、20000req / 10sec 結果:2xx → 99%以上 リクエスト過多 → ALB 503
ならない memcached必要やん! 伸びすぎた草
ELB が503返さない memcached 必要やん!
レスポンスタイム改 善 memcached 必要やん!
DBコネクション枯 渇しない memcached 必要やん!
ECSのメトリクスが穏やかになっている スパイクしても、スケールする余裕ある。。。
memcached 頑張ってるね
・memcached ・memcachedを活かすplugin(w3-total-cache) ・pluginの使用方法もリポジトリで解説してました まとめ:強さのポイント
ベストプラクティス + α
EC2のスケール管理辛い + そういえば、 認証必要だった
・スケール管理を楽にしよう EC2 → ECS ・認証 社内向けのためコンテンツ・コンテンツに掲載されている画像・動画類 → 社内のSSO通った人のみ ベストプラクティス +
α
構成図でみる認証経路
・①⇔④ CloudFront - ALB 間はOIDC使う(やったことある) ・①⇔② CloudFront - S3間どうしよう(やったことない) 認証は、社内独自SSO(CASSO)
え、Lambda@EdgeとCognito 準備するの・・・ Lambda + Cognito大げさ・・・ 公式見ると実装例ある!が・・・・
世にあるのもそ れに追随する が多い・・
ALB ⇔ S3 に認証を寄せるか 副作用:CloudFrontのキャッシュ使わないことになるかもだけど。安全第一 参考例あるかな・・・・ 近いのあった!!!! リリースが昨年末 1. VPC
Endpointを準備 2. ALBのターゲットグループに設定 これこれ感
認証込み構成図
・EC2 → ECS Fargate ・認証 ALB ⇔ VPC Endpoint ⇔S3
1. すべての認証経路をALBのOIDCに寄せ、サーバーサイドに リクエストが届かない(便利!) 2. アプリ側で認証を実装しない(差分少なくて楽!) +α の まとめ
今回やってみた感想
ベストプラクティス は 裏切らない
・認証はさんだ時のキャッシュ(CloudFront)の扱い方 headerとかcookieとかの条件が難しいのでパス!安全第一 苦労したところ①
・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/ 苦労したところ②
流れ VPC Endpoint作成 ↓ ENIからIPアドレス抽出 ↓ ALBのターゲットグループ に追加
次の改善点
次の改善点 ・CloudFront入れたけど、まだキャッシュさせてるものない(副作用) → ホワイトペーパーにヒントがありそう ・ALB ⇔VPC Endpoint ⇔ S3間のキャッシュ →
AWS File CacheかAWS StorageGateway使えそう? ・誰でも使えるようにしたい → ConstructHub、Github、Qiita等で共有
現場からは以上です。