7年ほど前にインフラを勉強するためにVPSに構築したWordPressのブログ。時は移り変わり、アプリケーションもインフラもパブリッククラウドは様変わりしました。このセッションでは、一台のVPSだけで運用していたWordPressのブログを、AWSの各種マネージドサービスとNext.jsをフル活用した構成に移行するまでの全過程をお届けします。
VPS運⽤のWordPressブログをAWSフル活⽤したモダン構成にする全過程2022/7/26CX事業本部 MAD事業部濱⽥孝治（ハマコー）
View Slide
2自己紹介濱⽥孝治（ハマコー）• CX事業本部 （元）MAD事業部⻑• Japan APN Ambassador 2020• JAWS-UG コンテナ⽀部運営• 好きなサービス︓ECS, EKS, CloudFormation• 好きな⾔葉「わっしょい」• @hamako9999• 最近ハマってるもの︓Vampire Survivors、プロセカ（推しもいますが、30分全て⾷い潰すので今⽇は控えます）
3いつものアレの時間ですよ
4今回の登壇きっかけVPS作ってWordPress運⽤してみたらめちゃくちゃ勉強になったから• 前職でアプリエンジニアやってたが、インフラ⽅⾯の知識が皆無だった• なんとかせねばと思い、VPSを契約しWordPressをインストールしまがりなりにも運⽤してみた• いろんなミドルウェアやLinuxのお作法が⾝につき異常に勉強になった ぶっちゃけクラスメソッドへの転職のきっかけの一つ
5ということは今このVPSを更にモダンにしたらめっちゃ勉強になるのでは︕︖
6作業始める前のハマコーが持っていた前提知識• React︓今回始めて触りました• Next.js︓今回始めて触りました• Amplify︓ほぼ始めて触りました• App Runner︓好きです• Aurora Serverless v2︓今回始めて触りました
7作業始める前のハマコーが持っていた前提知識• React︓今回始めて触りました• Next.js︓今回始めて触りました• Amplify︓ほぼ始めて触りました• App Runner︓好きです• Aurora Serverless v2︓今回始めて触りました途中泣きそうなぐらいつらかったけど、森茂先生の協力の元なんとかなりました。この場を借りてお礼申し上げます！！
8喋ること喋らないこと喋ること• モダンな構成にしていくための構成の勘所• 各技術要素とAWSサービスとの関連喋らないこと• WordPress⾃体の詳細な解説• ReactやNext.js⾃体の詳細な解説
9今回の登壇の趣旨WordPressの移⾏を題材にすることでAWSのモダンなサービスがどのようなユースケースで使えるのかを味わってもらう
10今⽇のセッションで持ち帰ってもらいたいこと以下のうちどれかを触るアツい気持ちReact、Next.jsAmplifyAurora Serverless v2App Runner
11Agenda• 移⾏前後の構成解説• 移⾏⼿順①︓Route 53とEC2の導⼊• 移⾏⼿順②︓Next.jsとAmplifyの導⼊• 移⾏⼿順③︓Aurora Serverless v2の導⼊• 移⾏⼿順④︓App Runnerの導⼊• 振り返りとまとめ
12移⾏前後の構成解説
13Agenda• 移⾏前後の構成解説• 移⾏⼿順①︓Route 53とEC2の導⼊• 移⾏⼿順②︓Next.jsとAmplifyの導⼊• 移⾏⼿順③︓Aurora Serverless v2の導⼊• 移⾏⼿順④︓App Runnerの導⼊• 振り返りとまとめ
14最初のインプット移⾏前後の構成を把握して話の流れを抑えておきます
15移⾏前構成図hamako9999.netを8年ほど前に購入VPSのIPアドレスをAレコード登録2013年9月に契約記事文中の画像はflickrに格納（MarsEditの機能で自動的にアップロード）
16さくらのVPSとは︖• SAKURA internetが運営するVPS• VPSとは︖• Virtual Private Server• ざっくり⾔うとサーバー⼀つを丸々利⽤できるサービス• 契約するとアクセス情報が払い出されて、SSHアクセスに必要な鍵の設定やミドルウェアの導⼊などなんでも好きにできる• AWSではLightsailがVPS相当• 価格とスペックのバランスが良く、⾮常にナイスなサービス
17さくらのVPS契約状況• 利⽤期間︓2013/9/3〜• 年払いで⽉1421円• Nginxでリバースプロキシキャッシュを⼊れていれば、コレぐらいのスペックでも全然問題ない
18アクセス数（PV）• ピーク時⽉間PV︓2016年7⽉に28万8千（今は6000程度）• ⼀時期「モバイルバッテリー ⽐較」で検索2位に• 「ポケモン Go」が出たときめっちゃ売れた• 最後の記事更新は2017年11⽉ → 以後放置
19その他サイト情報• WordPress:4.9.20• PHP︓5.6.18• nginx︓1.10.2• MySQL︓5.1.73• 格納記事数︓約110
20移⾏後構成図Value Domainから移行WordpressのPHP部分を移行MySQLを移行新規でNext.jsを構築 APIにGraphQLを利用
21移⾏⼿順①Route 53とEC2の導⼊
22Agenda• 移⾏前後の構成解説• 移⾏⼿順①︓Route 53とEC2の導⼊• 移⾏⼿順②︓Next.jsとAmplifyの導⼊• 移⾏⼿順③︓Aurora Serverless v2の導⼊• 移⾏⼿順④︓App Runnerの導⼊• 振り返りとまとめ
23ここでやりたいこと移⾏のベース構築
24ここでやりたいことの考え⽅今後の作業をスムーズに進めるため、環境を全てAWSに持ってくる• Route 53の導⼊• ドメイン全て移⾏（ネームサーバーの移譲ではなく）• AmplifyやApp Runnerはカスタムドメインが設定できるため、Route 53で管理したほうが何かと便利• EC2の導⼊• 各種AWSサービスを増やしながら動作確認するベースとして構築
25作業前構成
26作業後構成ドメインのAレコードにEC2のEIPを指定EIPをアタッチしてパブリックサブネットに構築PHP（Wordpress）、MySQLをインストール
27移⾏作業︓Route 53の導⼊センシティブな作業だけれど、AWSの公式ドキュメントが⾮常に丁寧に作られているので、それに基づいて慎重にやれば⼤丈夫• 公式︓ドメイン登録の Amazon Route 53 への移管• VALUE-DOMAINやお名前.comなどからの移⾏であれば、情報はいろいろ出てくる• EC2の導⼊前に独⽴して先にやるのが良い（VPSを運⽤している間は、Route 53のAレコードはVPSのIPアドレスにしておく）
28移⾏作業︓Route 53の導⼊https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/domain-transfer-to-route-53.html
29移⾏作業︓EC2の導⼊実際やるとき、以下の2つで迷う• 案①︓VPSをまるまるEC2移⾏• CloudEndure Migrationなどを利⽤してごっそり移⾏• 案②︓新規でEC2構築• EC2を新規で構築し、そこにイチからミドルウェアをインストールし、DBをインポートする
30移⾏作業︓EC2の導⼊実際やるとき、以下の2つで迷う• 案①︓VPSをまるまるEC2移⾏• CloudEndure Migrationなどを利⽤してごっそり移⾏• 案②︓新規でEC2構築• EC2を新規で構築し、そこにイチからミドルウェアをインストールし、DBをインポートする⼀⾒⾯倒くさそうだけれどこちらを採⽤
31案②︓新規でEC2構築ヘッドレスCMSとして利⽤するため、WordPressを可能な限り素の状態に戻しておきたかった• 運⽤が⻑いほど様々なカスタマイズやプラグインやテーマが導⼊され、それに合わせてDBスキーマも変更されがち• ヘッドレスCMSとして使う場合、テーマや⼤部分のプラグインは不要• DBをインポートした後、最新のWordpress（⾃分は6.0.1）を起動し動作確認する• このとき、必要であればDBのスキーマ更新が⾃動的に⾛る• ヘッドレスCMSについては、後述
32案②︓新規でEC2構築公式の下記⼿順通りにやれば、1時間ぐらいで終了• チュートリアル: Amazon Linux 2 に LAMP ウェブサーバーをインストールする• チュートリアル: Amazon Linux 2 での WordPressブログのホスト後は、VPSからmysqldumpとかで抜き出したデータをEC2のMySQLにインポートして管理画⾯が起動するところまで確認
33（余談）VPC作成ウィザードが神すぎた昔のしか知らない⼈は⼤興奮間違いなし︕︕
34参考︓CloudEndure Migrationの使い⽅https://dev.classmethod.jp/articles/migration_with_cloudendure/
35ここまでで移⾏のベース構築が完了
36移⾏⼿順②Next.jsとAmplifyの導⼊
37Agenda• 移⾏前後の構成解説• 移⾏⼿順①︓Route 53とEC2の導⼊• 移⾏⼿順②︓Next.jsとAmplifyの導⼊• 移⾏⼿順③︓Aurora Serverless v2の導⼊• 移⾏⼿順④︓App Runnerの導⼊• 振り返りとまとめ個⼈的に⼀番楽しかったやつ
38ここでやりたいことWordpressをヘッドレスCMSとして利⽤する⼿段を検討し検証しながら構築する
39作業前構成
40作業⼿順1. WordPressにGraphQLのエンドポイントを⽣やす2. ローカル環境でNext.jsでGraphQL経由でSSGしてみる3. 動作確認したNext.jsをAmplifyにデプロイする
41作業後構成Amplify上でNext.jsを動作させ、GraphQLでEC2にアクセス
42作業⼿順1WordPressにGraphQLのエンドポイントを⽣やす
43ヘッドレスCMSとはCMS（Contents Management System）の画⾯描画（ヘッド）部分と記事管理部分を分離したシステムの事
44ヘッドレスCMSとは従来のパターン ヘッドレスCMSの場合SPAフレームワークでレンダリング• Angular• Vue• React
45WordPressのヘッドレスCMS化に必要なものWordPressでのAPIの提供⽅法は⼤きく２つ1. WordPress REST API• 以前はプラグインとして提供されていたが2016年12⽉にリリースされたWordPress4.7から正式に採⽤された• デフォルトで有効化されている2. WPGraphQL• GraphQLのエンドポイントをWordPressに作成するプラグイン• オープンソースだがドキュメントも⾮常に充実していて良い
46WordPressのヘッドレスCMS化に必要なものWordPressでのAPIの提供⽅法は⼤きく２つ1. WordPress REST API• 以前はプラグインとして提供されていたが2016年12⽉にリリースされたWordPress4.7から正式に採⽤された• デフォルトで有効化されている2. WPGraphQL• GraphQLのエンドポイントをWordPressに作成するプラグイン• オープンソースだがドキュメントも⾮常に充実していて良いこちらを採⽤
47WPGraphQL• https://www.wpgraphql.com/• メインスポンサーはWP Engine社• WordPressのマネージドホスティングサービスのパイオニア• インストールするだけでGraphQLエンドポイントが⽣えるhttps://example.com/graphql• GraphQL実⾏専⽤IDEが付属• ドキュメントが⾮常に充実• Getting StartedやGuideが完璧• 単なるプラグインのページの域を超えている
48WPGraphQLクエリの履歴管理、QueryComposerなどもあり、超絶便利
49GraphQLの動作確認プラグインインストール後、作成されたGraphQLエンドポイントに対して、⾃分のクライアントから動作確認動作確認には、mac⽤クライアントのAltair GraphQL Clientを利⽤
50作業⼿順2ローカル環境でNext.jsでGraphQL経由でSSGしてみる
51Reactとは︖React（https://ja.reactjs.org/）• ユーザーインターフェース構築のためのJavaScriptライブラリ• 宣⾔的なView、コンポーネントベース、どこでも使える（React Native）• 開発はFacebook（Meta社）• ⽇本語めっちゃ充実しているので、学習は公式サイトだけでいけそう
52Reactを試すにはローカル環境の構築は異常に簡単• Node.js環境の構築• お気に⼊りのエディタの⽤意（ハマコーはVSCode）• npx create-react-app my-app• cd my-app• npm start• http://localhost:3000/にアクセス
53しばしお勉強タイム「モダンJavaScriptの基本から始めるReact実践の教科書」• React実践の前に必須なモダンJavaScriptの基本から学べる• Reactの基本を網羅的に学べる• TypeScriptの活⽤も学べる• 最近のJavaScriptやTypeScriptが不安な⼈も⼀気にキャッチアップできるのオススメ
54Next.jsとは︖Next.js（https://nextjs.org/）• Reactベースのプロダクション向けフレームワーク• 静的とサーバーでのハイブリッドレンダリング、TypeScriptサポート、スマートバンドル、ルーティングのプリフェッチなど、プロダクション運⽤に必要な機能を網羅したフレームワーク• 開発はVercel社
55Next.jsを試すにはローカル環境の構築は異常に簡単• Node.js環境の構築• お気に⼊りのエディタの⽤意（ハマコーはVSCode）• npx create-next-app nextjs-blog• cd nextjs-blog• npm run dev• http://localhost:3000/にアクセス
56しばしお勉強タイム「公式のStart Learning」• 英語• めちゃくちゃ良い• ReactからNext.jsまで全ての解説が網羅的になされている• DeepL使ってもなんでも良いので特に解説書とかもってなければ、確実にオススメ
57ここまでとりあえずReactとNext.jsの雰囲気がわかりましたほな、実際フロントエンドどうやって作りましょ︖
58Next.jsのexamplesにあるサンプルを利⽤cms-wordpress• A statically generated blog example usingNext.js and WordPress• Vercel社作成のNext.jsとWordpressでSSGするサンプルリポジトリ• 背景として、これがGraphQLを使ってるからGraphQLのエンドポイントを⽤意してみた• npx create-next-app --example cms-wordpress cms-wordpress-app
59利⽤⽅法• プロジェクト作成• .env.localファイルの⽤意• モジュールインストールとローカルテスト• http://localhost:3000/にアクセスWORDPRESS_API_URL=https://example.com/graphqlnpx create-next-app --example cms-wordpress cms-wordpress-appnpm installnpm run dev先程作ったGraphQLのエンドポイント
60ビルドログこれでエラーが出なければ万々歳だけれど、おそらく何かでるはずググりながらなんとかしよう
61ハマコー環境ででたエラーnext/image Un-configured Host• next.config.jsに画像で利⽤するドメインが設定されていないために出るエラー• 以下の要領で、エラー⾒ながら利⽤ドメインを追加module.exports = {images: {domains: [process.env.WORDPRESS_API_URL.match(/(http(?:s)?:¥/¥/)(.*)/)[2], // Valid WP Image'2.gravatar.com’,'secure.gravatar.com’,'hamako9999.net’, // added domain'1.gravatar.com’ // added domain],},}
62どうでしょう︖でたかな︖localhostだけれど、今までWordPressの慣れた画⾯でみていたコンテンツが全く別のレイアウトでNext.jsで表⽰されると物凄く興奮します。この興奮、⼤事にしたいですね。
63作業⼿順3動作確認したNext.jsのサンプルをAmplifyにデプロイする
64ついにここまで作ったNext.jsプロジェクトをAWS環境にデプロイしますAmplifyの凄さに興奮しましょう
65Next.jsのデプロイに必要なものは︖単純に考えてもこれぐらいのリソースが必要• 静的ファイルの保存場所︓S3• S3格納の静的ファイルを配信︓CloudFront• 証明書︓Certificate Manager• デプロイのためのパイプライン︓CodePipeline• Next.jsでのビルド︓CodeBuild
66Next.jsのデプロイに必要なものは︖単純に考えてもこれぐらいのリソースが必要• 静的ファイルの保存場所︓S3• S3格納の静的ファイルを証明書つけて発⾏︓CloudFront• デプロイのためのパイプライン︓CodePipeline• Next.jsのビルド︓CodeBuildAWS Amplify
67AWS Amplifyとは
68AWS Amplifyとは正直できること多すぎて、全体像を掴むのに苦労しがち
69AWS Amplifyでできること以下の機能を組み合わせながら利⽤する• Amplify Studio• フルスタックアプリケーションの視覚的デプロイ• Amplify ライブラリ• 既存のAWSサービスへの接続• Amplify CLI• CLIワークフローでバックエンドを構成• Amplify ホスティング• コンテンツ配信ネットワークを介して、信頼性の⾼いウェブアプリをホスト
70AWS Amplifyでできること以下の機能を組み合わせながら利⽤する• Amplify Studio• フルスタックアプリケーションの視覚的デプロイ• Amplify ライブラリ• 既存のAWSサービスへの接続• Amplify CLI• CLIワークフローでバックエンドを構成• Amplify ホスティング• コンテンツ配信ネットワークを介して、信頼性の⾼いウェブアプリをホストこれを利⽤そしてこれが、異常に簡単で便利
71AWS Amplify利⽤⽅法
72AWS Amplify利⽤⽅法今回はこちら
73AWS Amplify利⽤⽅法︓リポジトリ選択
74AWS Amplify利⽤⽅法︓ブランチ設定デプロイ対象のブランチとmonorepoの場合のディレクトリを選択
75AWS Amplify利⽤⽅法︓ビルド設定CodeBuildのビルド設定が⾃動的にセットされる正直、なんでかわからんが、ごっつええ感じで⼊ってる
76さてさてこれでうまくいくかって︖そうは問屋がおろしませんよ
77エラー内容「バージョン不正」Next.jsのバージョン不正• VercelのサンプルはNext.jsのバージョンが12• 対して、Amplifyが対応しているNext.jsのバージョンは11.1.3が最新（2022年7⽉時点）• updating the Next.js version for an existing app
78対応「バージョン不正」対応するバージョンにpackage.jsonを変更
79エラー内容「環境変数設定」環境変数「WORDPRESS_API_URL」を設定する必要ありとのことローカル環境では、.env.productionに設定していれば動いていたけれど、なんで必要なのかよくわからん
80対応「環境変数設定」Amplifyのコンソールで、[アプリの設定] -> [環境変数]でビルド環境の環境変数を設定
81どうでしょう︖でたかな︖Amplifyの本番稼働URLにアクセスし、無事表⽰されるか確認。たったこれだけの⼿間で、ビルドパイプラインと静的ファイルホスティングが動作するのはめちゃくちゃ興奮します。
82ドメイン管理構築後のURLにカスタムドメインの追加が可能ドメイン名だけでアクセスする場合は、ここをEnableに設定。サブドメインにはブランチ名を指定可能。ここではmainブランチをサブドメインにデプロイされるように設定
83ここまでだいたい喋りたいことの8割ぐらいは完了しました
84Aurora Serverless v2の導⼊
85Agenda• 移⾏前後の構成解説• 移⾏⼿順①︓Route 53とEC2の導⼊• 移⾏⼿順②︓Next.jsとAmplifyの導⼊• 移⾏⼿順③︓Aurora Serverless v2の導⼊• 移⾏⼿順④︓App Runnerの導⼊• 振り返りとまとめ
86作業前構成
87作業⼿順1. EC2の中にあったMySQLをAurora Serverless v2に外だし
88作業後構成Aurora Serverless v2が爆誕
89なぜAurora Serverless v2を使うのか︖
90Aurora Serverless v2とはAuroraのオンデマンドAuto Scaling設定• Auroraを事前のインスタンスタイプのプロビジョニングをせずに利⽤可能• アプリケーションニーズに基づいて⾃動的に起動、シャットダウン、スケールアップ・ダウン• 標準のAuroraとServerlessの設定変更は、インスタンスタイプの変更ぐらいの感覚で可能EC2とLambdaは完全に別物だけれど、AuroraとAuroraServerlessは使い勝⼿はほぼ同じなので、気軽に使っちゃいましょう︕
91Aurora Serverless v2を使いたい理由Next.jsがSSG設定のため• Static Site Generationの略（静的サイト⽣成）• ビルド時にサーバ側でデータを取得しHTMLを⽣成• Amplifyであれば、CDN（CloudFront）にHTMLを格納
92Aurora Serverless v2を使いたい理由Next.jsがSSG設定のため• Static Site Generationの略（静的サイト⽣成）• ビルド時にサーバ側でデータを取得しHTMLを⽣成• Amplifyであれば、CDN（CloudFront）にHTMLを格納つまりは、アプリケーションサーバ経由のDBアクセスをビルド時のみに限定できるのでは︕︕︖︖
93Aurora Serverless v2のACU推移ACU最⼩1〜最⼤6設定でのACU推移。最初のデータ移⾏時にはマックス6まで。その後の検証期間中は概ね2以内で推移
94CSR/SSR/SSG/ISRが学びたいそこのあなたhttps://zenn.dev/a_da_chi/articles/105dac5573b2f5
95作業⼿順1EC2の中にあったMySQLをAuroraServerless v2に外だし
96Aurora Serverless v2構築
97Aurora Serverless v2構築
98さてさてこれでうまくいくかって︖そうは問屋がおろしませんよ
99エラー︓Capacity不⾜しばらく待っても駄⽬だったので、DBのサブネットグループを4AZに拡張し、作成に成功。こういうこともあるので、VPCもDBサブネットにも4AZはとりあえず作っておくのが良いすね。
100作成後のデータ導⼊従来のAuroraとほぼ同じ感覚で利⽤可能• EC2のMySQLからmysqldumpを実⾏• Aurora Serverless v2にデータインポート• wp-config.phpのDB接続先を変更して動作確認
101ここまでAurora Serverless v2の導⼊でだいぶモダンな雰囲気になりましたね︕
102App Runnerの導⼊
103Agenda• 移⾏前後の構成解説• 移⾏⼿順①︓Route 53とEC2の導⼊• 移⾏⼿順②︓Next.jsとAmplifyの導⼊• 移⾏⼿順③︓Aurora Serverless v2の導⼊• 移⾏⼿順④︓App Runnerの導⼊• 振り返りとまとめ
104作業前構成
105作業⼿順1. WordPressコンテナを作成し動作確認2. ECRにイメージをプッシュ3. App Runnerでデプロイ
106移⾏後構成図App Runnerが爆誕（ECR経由でデプロイ）
107なぜApp Runnerを使うのか︖
108App Runnerとはフルマネージド型コンテナデプロイ環境• サーバー、ネットワーク、ロードバランサー、オートスケーリング設定が不要• ECRプッシュからの⾃動デプロイが可能• VPCリソースへのアクセスも可能（2022年2⽉より）• もちろん、Aurora Serverless v2も利⽤可能
109App Runnerを使いたい理由Next.jsがSSG設定のため• プロビジョニングされアクティブではない場合、最低料⾦（⽉6.48USD）で利⽤可能• アクティブな場合、割り当てたvCPUとメモリの値で従量課⾦ビルドしない時は最低料⾦で利⽤可能︕（Fargateよりもちろん安い）
110App RunnerのActive instancesの推移Next.jsでのビルド時のみinstanceが1つ起動し、それ以外は0に収束
111作業⼿順1. WordPressコンテナを作成し動作確認2. ECRにイメージをプッシュ3. App Runnerでデプロイ
112利⽤するDocker ImageWordPress Official Image• WordPressを利⽤するとき頻出の設定が環境変数で設定可能• -e WORDPRESS_DB_HOST• -e WORDPRESS_DB_USER• -e WORDPRESS_DB_PASSWORD• テーマやプラグインを設定する専⽤ディレクトリも有• /var/www/html/wp-content/themes/• /var/www/html/wp-content/plugins/• 基本的にEC2にインストールしたWordPressと同じバージョンを使う
113Dockerfile例FROM wordpress:6.0.1COPY stinger3ver20130925/ /var/www/html/wp-content/themes/stinger3ver20130925/COPY wp-graphql/ /var/www/html/wp-content/plugins/wp-graphql/COPY uploads/ /var/www/html/wp-content/uploads/Dockefileは超シンプルEC2に新規でWordPressをインストールしヘッドレスCMSとして最⼩構成で構築したのは、WordPressをコンテナ化しやすくする背景もありました
114イメージビルドしてECRにプッシュdocker build -t hamako9999-blog:1.3 .docker tag hamako9999-blog:1.3 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/hamako9999-blog:1.3docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/hamako9999-blog:1.3今回GitHubからECRへのイメージビルドとプッシュは⾃動化してないですが、GitHub Actionsとか使ってサクッとやれば、ソースコードからの⾃動デプロイも簡単に構築可能
115App Runnerの構築（基本部分）123456789012ソースコードからのデプロイに対応しているのは、Python、Java、Node.jsのみ（2022年7⽉現在）
116App Runnerの構築（プロビジョニング設定）⾃分のサイトの規模（記事数110程度）であれば、これぐらいのスペックでも⼗分Next.jsのビルドは通る
117App Runnerの構築（環境変数）コンテナ使うとき必須の環境変数も、もちろん定義可能
118App Runnerの構築（ネットワーク設定）VPCでApp Runner起動する場合、最初にVPCコネクタを作成し、その後起動するSubnetとSecurityGroupを設定
119App Runnerの構築（デプロイ完了）⾃動的にECRからのプルとデプロイが⾛る。事前にEC2で動作確認しておいたイメージから、AppRunnerのデプロイでは、特にエラーはなかった
120Next.jsでのビルド再確認WORDPRESS_API_URIのエンドポイントを、App Runnerで払い出されたドメイン指定して、GraphQLのエンドポイントからビルドが通ればOK。お疲れさまでした︕︕
121というわけでここにあるよ︕︕https://main.hamako9999.net/
122振り返りとまとめ
123移⾏前hamako9999.netを8年ほど前に購入VPSのIPアドレスをAレコードを登録2013年9月に契約記事文中の画像はflickrに格納（MarsEditの機能で自動的にアップロード）
124移⾏①︓Route 53とEC2の導⼊ドメインのAレコードにEC2のEIPを指定EIPをアタッチしてパブリックサブネットに構築PHP（Wordpress）、MySQLをインストール
125移⾏②︓Next.jsとAmplifyの導⼊Amplify上でNext.jsを動作させ、GraphQLでEC2にアクセス
126移⾏③︓Aurora Serverless v2の導⼊Aurora Serverless v2が爆誕
127移⾏④︓App Runnerの導⼊App Runnerが爆誕（ECR経由でデプロイ）
128まとめWordPressをヘッドレスCMS前提の構成とし、Next.jsのSSGを活⽤することで、モダンな構成を検討可能︕• Amplify ホスティング︓関連リソースを隠蔽し、Webサイトのホスティングに特化• Aurora Serverless v2︓驚異のオンデマンドRDB。普段利⽤しなければコスト効率は⾮常に⾼い• App Runner︓フルマネージドコンテナサービス。普段利⽤しなければコスト効率は良い
129最後に伝えたいこと新時代のサービスが登場し、簡単にデプロイでき、かつオンデマンドでスケールできるものが充実してきたので、是⾮今⽇の内容をヒントにみなさんのアプリケーション構成を⾒直すきっかけにしてもらえればと思います︕
hamadakoji
cyberagentdevelopers
sr2mg4
tacck
jeromevdl
oracle4engineer
takemikami
skrb
x_ttyszk
yusuke0519
microcms
yujisoftware
hankehly
robhawkes
marcelosomers
revolveconf
sferik
mclloyd
kneath
jonrohan
mza
trishagee
brettharned
zakiyama
keathley