個人的にブログサイト作ってみようと思い立ち、独学でXAMPPを初めて個人で運用すること15年ほどになりました。制約が多い一般的なブログ投稿サイトに対して自由度が高く、色々と学べるということで始めました。PHPのバージョンアップに伴うリファクタリングをしてみたり、オーディオ趣味と合わせたショップサイトの運営も2年ほど行ったりもしました。2012サーバーのOSを利用しておりました。古いOSということで2023年10月でサポートも終了します。故障した3枚のHDDの内2枚を交換し、1枚は購入をせずに利用を中止しました。その他、FANの異音でかれこれ4回ほどFAN交換もしています。クラウドを検討することに機材を新調してオンプレミス運用を続けるか、クラウド化するかを検討しました。PRIMERGYという本格的なタワー型サーバーPCを使っていますが値段はかなり高騰しているようです。本ナレッジは私が思う基礎知識を述べておりますが無料公開のナレッジのためある程度は大雑把にまとめています。完璧な手順書ではなく、あくまで参考情報として基礎知識の補強程度としてお読みいただきますようお願いいたします。画像が小さいですが直接画像を開いて頂ければ少しは見やすくなると思います。鮮明な画像が欲しい方や本ナレッジの内容を元により詳しく知りたいという方、その他追加のご希望があれば単発プランでご相談を頂ければと思います。AWSの料金については2023年5月31日時点で情報を元に記載しています。最新の請求金額は変わっている可能性がありますのでご注意ください。動作テスト運用テストクラウドの検討オンプレミス運用の良いところ・悪いところを考えつつ、私自身のニーズとしてどのようにしたいかを考えました。オンプレミス運用のデメリットが目立つ同性能のサーバーPCはかなり値上がりしている空調管理の手間がかかる電気代高騰の懸念がある5~10年程度で機器入れ替えが必要ハードウェアメンテナンスも必要で手間暇がかかるオンプレミス運用のメリットも一応ありますハイスペックPCで運用しやすい(サーバーPCやサーバーOSはかなりお高い)HDDタワーなどで大容量化しやすいバックアップ時などローカルにサーバーがあれば転送速度はかなり早くできる外部データ配置しないのでセキュリティーに強くできる(結局はセキュリティー意識の問題)クラウド移行をすることにそれでもメリットに対してデメリットの方が大きく感じてしまいました。他にもしたいことがあるのでハードウェア周りの対応に時間を掛けたくないというのが大きいです。以下の状況からハイスペックなサーバーを購入する必要はないだろうという判断になりました。クラウドへ移行を行うことにしました。クラウドだとクラウドの方が安そうセキュリティーに関しては厳しめに設定するのでまず問題ない独自WAFでbotアクセスはある程度の条件で自動拒否する仕組みがあるポート80/443以外は自宅以外からアクセスできない(固定IPでアクセス制限)AWSアカウントはMFAで厳しくしてあるそもそも本当に大事なものはクラウドに置かない現サーバーの状況を把握まずは何をクラウドに移行して縮小化(予定)したオンプレミス環境に何を残すかを考えました。私の場合はサーバーは「ウェブサイト運用」と「データとソースコードのバックアップ」にしか使っていないです。バックアップは容量が大きいのでデータ容量費に転送時間と転送費用がネックになります。万が一のクラウドサービス停止やデータセンターの事故でデータの喪失は避けたいです。そのため自宅とクラウドの両方にデータのバックアップがあるのが理想と考えることにしました。私が運用しているウェブサイトはXAMPPでしたのでApache(PHP)+MySQLの組み合わせです。そのため、必要なデータは以下になります。Apache・MySQL・PHPの設定ファイルPHPのスクリプト(ソースコード)MySQLのデータ(データベース)ブログのデータ(バイナリデータ)SSL証明書のデータこれらの各データをクラウド化する上で作業しやすくしつつ、現環境に影響がでないようにバックアップしました。(作業用)のフォルダへ一通りコピーしました。この時点で大まかなデータの総容量を確認しておきます。※EC2を起動する際のディスクの容量を決める際の重要な数字になります。新環境の設計・整備(インフラ周り)大きな目標としてオンプレミス機材購入費とクラウド運用費を同じまたは、より費用を抑えたたいを目指すところとしました。そのため新環境のクラウドでは、t4g.microのインスタンスタイプを前提に進めることにしました。t4g.microで運用したい(できれば)バーストの制限はなし、独自WAFである程度制限されるためディスクは初期50GBくらい(セットアップ時は極端に大きなサイズにはしない)データの抽出時に25GBくらいとわかったので50GBとしました。10年で25GB程度であれば50GBでも10年くらいは動作しそうです。(ARM64)という部分です。それでも大文字小文字と実行パスの2つ以外には問題にならない想定でしたので気にせず続行することにしました。ディスクの容量はデータ抽出時の数値を参考に最初はちょっと余裕があるくらいでEC2を立ち上げました。EC2のインスタンスのバックアップとしてEBSのサイズを指定してAMIが作れます。最初に決めたサイズよりも小さくするのが面倒なので大きくしすぎないようにします。性能で、月々1125円(140円/ドル)くらいとなります。インスタンスを起動してセットアップ要件が決まったのでEC2インスタンスを起動してセットアップを行いました。VPC/セキュリティーグループなどは今回のブログサイト運用専用に新規に整えました。別の学習用のVPCがありますがそちらとは完全に分離して管理することにしました。EC2操作用のSSH接続ソフトウェアはMobaextermを使っています。今回、ウェブサーバーのソフトウェアをapacheからnginxに変えたので設定ファイルはあまり参考になりませんでした。Apacheは機能が多いためか設定も多くて設定項目を探すのが大変ですが、nginxは主要ファイルが3つのみで行数も少ないのでシンプルです。MariaDBへの置き換えはメモリ使用量の差が多きすぎるので別の開発で使っているmariadbの設定を元に調整しました。パフォーマンス重視ではなくてメモリ使用量を優先しての設定です。Linux開始後の各ソフトウェアが起動した状態でメモリ使用量は全体で300MB以内くらいになっています。nginx/php-fpm/mariadbはメモリ使用量を見つつ、パフォーマンスが極端に下がらないように注意しながら設定ファイルを作りました。mariadbが400MB前後、nginx+php-fpmが300MB前後くらいを想定しておくことで1GiBのメモリで足りる想定です。重たい処理のデータベースのバックアップ処理を行ってもmariadbが20%以下なので400MBを超えることはなさそうです。nginxの設定ファイルでは大量にリクエストを受けすぎないくらいにしました。1クライアントに占有されるのも困るので同時接続制限や帯域制限なども行ってあります。後は運用中にトラブルになりやすいログ管理も事前に対策してあります。あとは、ディスク容量の確保に不要なキャッシュなども削除しました。抽出したデータをEC2へコピーMariaDBへデータベースのバックアップをリストアデータベースのアクセス用アカウントの追加ついでにバックアップ・メンテナンス用のアカウントも追加PHPのスクリプトのコピーブログのデータのコピー(バイナリデータ)SSL証明書のデータのコピーこのタイミングではひとまず、オンプレミス運用で利用していたPHPのスクリプトをそのままEC2へアップロードしました。ソースコードやデータのコピーに関してはWinSCPというソフトウェアを使っています。Linux用にスクリプトなどを調整PHPのスクリプトをLinuxに合わせる大文字小文字のファイル名やディレクトリ名に相違がないか確認ある程度の気づく範囲で修正しつつ動作テストの際にその都度直すくらいのチェックのみです。データベース内にWindowsの絶対パスがないかチェックパスがWindowsようになっているレコードが1つだけあったのでupdateのsqlとreplase関数でクエリで置き換えました。PHPソースコードはローカル(Windows11)上でVSCodeでフォルダを開いて一通り修正しました。修正箇所が見つかったらローカルで直してEC2へアップロードを行うという手順の繰返しです。PHP8系へのアップデートPHP5系からPHP8系へのアップデートでのトラブルも少しありました。一部のPEARでインストールするソースコードがPHP8対応されていないようでこの辺りは自前で直す必要がありました。セキュリティー的にどの機能とは言えませんが以下のようなエラーがありました。class()とクラス生成を変数に入れる機能が7.0で削除どうやらすでにメンテナンスされていないものなので使い続けるのは良くなさそうですね。その他、オリジナルフレームワークに関してはPHP8にしたから実行できないというのは1つだけでした。動作テスト主に以下のような内容を確認しました。会員制のブログサイトなのでログインできるか、登録したブログの履歴が見えるかリンクから別のページに移動できるかオンプレミス運用中のウェブサイトと同じ挙動であるかPHPやnginxのログを見てエラーや警告がないかもうほったらかしですが私自身が更新していたブログサイトのデータが残っているのでこちらを元に動作確認を進めました。以下の画像はブログに投稿した画像一覧表示を行う機能の動作確認をしていた時のものです。ブログ投稿サイトなので画像が新規にアップロードできるかやブログ記事に画像が張り付けられるかなどを確認しました。PHPスクリプトの設計として、ルートディレクトリが一致すればWindowsでもLinuxでも相対的にアクセスするようにしていました。そのため、大文字小文字のLinux特有の問題がなければ基本的には動作すると考えています。実際ほとんどの動作は問題ありませんでした。動作していなくて戸惑ったところとしては一部の機能が有効になっていなかったところです。nginxとphpの設定ファイルを新しく作っているウェブサイトの設定を参考にしたために起きていた問題です。具体的にはセッション管理処理とMariaDBのAutoCommitの設定ですね。運用テスト家族が更新しているウェブサイトこちらはいつも使っている人が正しく使えるかどうかの確認してもらう段階です。問題なさそうな感じでしたので数日ほど様子見て問題がなければ完全にクラウド移行完了となりそうです。時々はメモリ使用量をみたりしていますが、ソフトウェアが異常終了するような現象はなさそうです。一通りの環境移行が終わったところでディスク容量が50%を超えていました。初期は50GBでしたがOSやソフトウェア関連のアップデートで25GB以上になってしまったので、60GBにしました。作業途中にAMIを作ってバックアップで効率アップソフトウェアのインストールやデータのコピーなど時々時間が掛かる作業があります。この時にある程度のめどが立ったタイミングでAMIを作っておくと何かしらのミスで戻したいというのがスムーズに行えます。IPを関連付けしなおすだけというはとっても楽ですね。モニタリングで異常がないかチェック1日動かしてみてのモニタリングの様子ですがスパイクはあれど大きな問題はなさそうです。S3への1回目のバックアップでネットワーク送信料が大きく跳ね上がっていますが以降はスパイクも少ないので通信量による料金過多の心配も少なそうです。クラウド化する前からBotなどで大量のリクエストが来た際のネットワーク帯域の使用量が懸念でした。モニタリングの状況を見る限り、異常なBotアクセスに対しては独自WAFがちゃんと動いているようです。一時的に独自WAFを外したら10MB/sくらいになったので放置していたら結構な通信料金取られそうですね・・・(怖い)S3へのバックアップS3とEC2のSSDとの同期処理でS3へバックアップを行ってみました。初回アップロードなので25GBくらいありましたが10~15分くらいで転送が終了しました。転送速度はAWS内部のネットワークということもあり1Gbpsに近い速度で転送されました。オンプレミス運用からクラウド運用への引っ越し時のユーザーコンテンツの個数や容量は以下の通りです。費用の発生状況ひとまず1週間ほど動かした状態での料金発生状況は以下の通りです。機能修正やS3の整理などで時々追加料金が発生していますが概ね運用コストとしてて初月は3千円程度くらいになりそうです。EC2からS3への初回のバックアップの転送料金が$1、S3のゴミデータの整理などで$5ほど発生しています。※コストリストにEFS・ECR・CloudFront・SNSなどの他のサービスも記載されていますがこれらは別の検証で発生している料金となります。落ち着いた状態での約1か月の費用1日$1未満となっています。消費税などが月初めに加算されますので最終的には1日$1ちょいといったところでしょうか。Budgetsは1週間に1度、全体の費用の通知をAWSからメールで送っているのでその費用です。AWSにログインしなくても発生している料金がわかるようにしておくのはかなり大事です。後は、意図しない料金発生などを検知できるように自分の予算に合わせたアラート機能なども活用するとさらに安心できます。