【ブログ移行計画①】AWSでWordPressを作成してみた
こんにちは、Taikiです。
先々ブログ移行を検討しており、勉強もかねて無料枠でAWSのインスタンスを作成しました。
細かな手順はオフィシャルサイトに多数あるため、ここでは大まかな流れと気になるポイントを掘り下げます。
目次はこちらです。
無料枠でインスタンス作成
まずは簡単な要件をまとめます。
無料枠でWordPress と言えばコンピューティングサービスですが、EC2かLightsailの二択がありましたので、違いを紹介します。
▼EC2
- EC2はコンピューティング機能のみが提供されている(ストレージやロードバランサ―別途契約要)
- 料金は従量制
- 停止している間は課金されない
- 柔軟性が高い
- 無料利用期間:12か月間無料
▼Lightsail
- ストレージ、スナップショット、ロードバランサー機能、ファイアウォール、DNSなど必要な機能がパッケージで提供されている
- 料金は月額最低3.5ドル(Linux/Unix)から最高240ドル(Windows Server)の月額固定料金
- 停止している間も課金される
- 柔軟性が低い
- 無料利用枠:1か月間無料
ECサイトなど商用目的ならEC2ですが、個人ユースならLightsailだと思います。今回は無料枠1年もあるので試しにEC2を選んでみました。無料利用枠のリンクも一応貼っておきます。
サポートプランの選択
サポートプランも幾つかあります。今回は個人契約なのでベーシックプランです。
この機会に理解を深めるため、ざっくりですが一覧にしてみました。
エンタープライズは月額15000ドル。。なぜこんなに高いのでしょうか。気になったので自分なりに調べてみました。
料金のウエイトを大きく占めるのは、Trusted Advisor、TAMへの直接アクセス、ホワイトグローブケースルーティングの3点だと思われます。
まずTrusted Advisorについてですが、これはAWS固有のサービスみたいですね。AWSの既知のノウハウを駆使しアーキテクチャや運用面に改善余地がないかを精査してくれます。例えばCPUの低いインスタンスだと、これだけ見直せばこのくらいディスカウントできる等が分かります。AWSは、インスタンスやディスク容量、稼働時間、通信量などで従量課金するため、見直す要素が増えればそれだけ節約効果を生みます。そのため、エンタープライズでは、Trusted Advisorの対象が全項目になっています。
次にテクニカルアカウントマネージャ(TAM)に直接アクセスする件ですが、これはAWSの専門家に相談できるサービスです。もし私が大手のCIOでこのサービスを受けられるなら、大規模なDXを検討する際に利用します。例えば、大量のOracleDBをAmzon Auroraに移行したり、WIndowsサーバーをLinuxに移行したりと、クラウド移行に伴い大幅なコストダウンを狙います。それを実行するにあたり、そのリスクや実行性、タイムスパンを調べるために色々と相談します。エンタープライスの月額料金は15,000USDですが、長期的にそれ以上の削減効果を見込めれば一時的でもこのプランを利用する価値はあると思います。
ホワイトグローブケースルーティングは、緊急度の高いサポートケースをAWSが優先的に解決に導くサービスです。例えば、クラウド移行プロジェクト中に未知の不具合が発生したり、クリティカルな問題にぶつかったときに、AWSの精鋭が優先的に助けてくれると心強いですよね。あくまで予想ですが、AWS最上位の プレミアコンサルティングパートナーは常時このサポートプランを契約しているのではないでしょうか。顧客のクラウド移行支援にあたり自社の開発環境で検証し躓いたときには直ぐに対応できるからです。最上位なのに解決できないとなると看板に傷が付きますからね。そして、その出費は移行料やリセールサービスで簡単に回収できると思います。
WordPressのカスタムEC2を選択
EC2では、Wordpressのプレインストール版が無料枠で用意されています。なぜでしょうか。今や世界中のWebサイトの3分の1はWordpressで作られています。そして未だエックスサーバーなどのレンタルサーバーの利用者も多いため、乗り換えの需要も多いはず。またスモールスタートで手軽に乗り換えやすいようt2.microのスモールサイズを無料枠にしておびき寄せているのでは、と思います。案の定、私もこのプランを選択しました。。
キーペアの作成
インスタンスを作成するタイミングでキーペアが作成されます。このキーペアはパブリックキーとプライベートキーを指し、通信の暗号化に利用されます。
プライベートキーは利用者側で保管しますが、これを無くしたりするとEC2のインスタンスに接続できなくなります。復旧するためには、先述したようにインスタンスを作成するタイミングで、キーペアを対応付します。詳細な手順はこちらのブログで紹介されています。
補足情報ですが、AMIはインスタンスを作成するための諸設定が保存されたテンプレートです。そのテンプレートを別でコピーする事も可能ですし、コピーしたテンプレートから同じインスタンスを立ち上げることも可能です。既存のインスタンスをカスタマイズし、そのインスタンスからカスタムAMIとして保存することも可能です。このWordPress付のAMIもカスタマイズされて提供されたものでしょう。有料でカスタムAMIを提供しているものもあるので、スクラッチで作成しなくても探せば構築の手間が省けそうですね。
出典:https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/AMIs.html
まとめ
AWSのナレッジは豊富なため実際の手順は殆ど困りませんでした。なので意識するところは、手順を追うことだけでなく、クラウド特有の料金パターンやアーキテクチャ、最適な運用方法を把握することだと思いました。直ぐに分かる知識よりは、がんばって調べて応用できる知恵の方が情報価値が高いからです。そのため今回は構築手順の中でも気になるポイントを掘り下げて解説してみました。
早速、次のフェーズである、ドメイン登録やデータ移行、ブログの公開までをまとめましたので、興味のある方ご覧ください。
今回の手順はオフィシャルにあるためご参考ください。