まえがき

個人でブログサイトを運営中

個人的にブログサイト作ってみようと思い立ち、独学でXAMPPを初めて個人で運用すること１５年ほどになりました。
制約が多い一般的なブログ投稿サイトに対して自由度が高く、色々と学べるということで始めました。
PHPのバージョンアップに伴うリファクタリングをしてみたり、オーディオ趣味と合わせたショップサイトの運営も２年ほど行ったりもしました。
最近は新しめの技術を取り入れた新サイトを作ろうと考えつつも多趣味すぎてあまり進んでいないですね・・・

OSサポート終了＆機材の老朽化

さて、そんな個人運営のブログサイトですが、Windows 2012サーバーのOSを利用しておりました。
かなり古いＯＳということで２０２３年１０月でサポートも終了します。

故障した３枚のHDDの内２枚を交換し、１枚は購入をせずに利用を中止しました。
その他、FANの異音でかれこれ４回ほどFAN交換もしています。

クラウドを検討することに

機材を新調してオンプレミス運用を続けるか、クラウド化するかを検討しました。
現在運用中のサーバースペックは 4 Core/8 Threadsで16GB RAMです。
Fujitsu Server PRIMERGYという本格的なタワー型サーバーPCを使っていますが値段はかなり高騰しているようです。

諸注意

本ナレッジは私が思う基礎知識を述べておりますが無料公開のナレッジのためある程度は大雑把にまとめています。
完璧な手順書ではなく、あくまで参考情報として基礎知識の補強程度としてお読みいただきますようお願いいたします。

画像が小さいですが直接画像を開いて頂ければ少しは見やすくなると思います。
より鮮明な画像が欲しい方や本ナレッジの内容を元により詳しく知りたいという方、その他追加のご希望があれば単発プランでご相談を頂ければと思います。

AWSの料金については2023年5月31日時点で情報を元に記載しています。
最新の請求金額は変わっている可能性がありますのでご注意ください。

クラウドの検討

オンプレミス運用の良いところ・悪いところを考えつつ、私自身のニーズとしてどのようにしたいかを考えました。

オンプレミス運用のデメリットが目立つ

同性能のサーバーPCはかなり値上がりしている
空調管理の手間がかかる
電気代高騰の懸念がある
５～１０年程度で機器入れ替えが必要
ハードウェアメンテナンスも必要で手間暇がかかる

オンプレミス運用のメリットも一応あります

ハイスペックPCで運用しやすい（サーバーPCやサーバーOSはかなりお高い）
HDDタワーなどで大容量化しやすい
バックアップ時などローカルにサーバーがあれば転送速度はかなり早くできる
外部データ配置しないのでセキュリティーに強くできる（結局はセキュリティー意識の問題）

クラウド移行をすることに

それでもメリットに対してデメリットの方が大きく感じてしまいました。
他にもしたいことがあるのでハードウェア周りの対応に時間を掛けたくないというのが大きいです。

以下の状況からハイスペックなサーバーを購入する必要はないだろうという判断になりました。
なのでクラウドへ移行を行うことにしました。

現構成のapache(php)+mysqlで合計1GiBメモリがあれば動作させられる
私自身の自宅サーバーの利用頻度が低い
私自身はソースコードや趣味のデータのバックアップに利用しているだけ
現行サーバーを止めることができない
家族が利用しているのでサーバーの停止はできない
AWSクラウドの利用料金が抑えやすくなった
ARM64のインスタンスなら月２千円程度で利用できそう
オンプレミス vs. クラウドだとクラウドの方が安そう
セキュリティーに関しては厳しめに設定するのでまず問題ない
独自WAFでbotアクセスはある程度の条件で自動拒否する仕組みがある
ポート80/443以外は自宅以外からアクセスできない（固定IPでアクセス制限）
AWSアカウントはMFAで厳しくしてある
そもそも本当に大事なものはクラウドに置かない

現サーバーの状況を把握

まずは何をクラウドに移行して縮小化（予定）したオンプレミス環境に何を残すかを考えました。

私の場合はサーバーは「ウェブサイト運用」と「データとソースコードのバックアップ」にしか使っていないです。
バックアップは容量が大きいのでデータ容量費に転送時間と転送費用がネックになります。
また、万が一のクラウドサービス停止やデータセンターの事故でデータの喪失は避けたいです。

そのため自宅とクラウドの両方にデータのバックアップがあるのが理想と考えることにしました。

クラウド化

*. ウェブサイト運用

オンプレミス運用

*. データ等のバックアップ

ウェブサイト運用に必要なデータを抽出

私が運用しているウェブサイトはXAMPPでしたのでApache(PHP)＋MySQLの組み合わせです。
そのため、必要なデータは以下になります。

Apache・MySQL・PHPの設定ファイル
PHPのスクリプト（ソースコード）
MySQLのデータ（データベース）
ブログのデータ（バイナリデータ）
SSL証明書のデータ

これらの各データをクラウド化する上で作業しやすくしつつ、現環境に影響がでないようにバックアップしました。

私の場合は、Windows Server (運用中)から手元のWindows 11 (作業用)のフォルダへ一通りコピーしました。

この時点で大まかなデータの総容量を確認しておきます。
※EC2を起動する際のディスクの容量を決める際の重要な数字になります。

新環境の設計・整備（インフラ周り）

大きな目標としてオンプレミス機材購入費とクラウド運用費を同じまたは、より費用を抑えたたいを目指すところとしました。
そのため新環境のクラウドでは、t4g.microのインスタンスタイプを前提に進めることにしました。

主要件

EC2：１台 t4g.microで運用したい（できれば）
バーストの制限はなし、独自WAFである程度制限されるため
ディスクは初期50GBくらい（セットアップ時は極端に大きなサイズにはしない）
データの抽出時に25GBくらいとわかったので50GBとしました。
10年で25GB程度であれば50GBでも10年くらいは動作しそうです。
Amazon Linux 2023を採用（AWSサポートの長いOSで安価なLinuxにしたい）
nginxとmariadbで運用したい（知識を得ておきたいソフトウェアなので）
phpは8系の最新にする（php7あたりでメモリ使用量が削減され、実行速度も改善された）
不要なソフトウェアはインストールしない
省メモリにするためDocker/コンテナ環境は使いません
ドメインは再利用（現行のドメインのまま進める）
マルチドメイン運用
ブログ投稿サイトとブログ記事閲覧用のURLは個別に
SSL対応（ログイン機能にブログ投稿機能などもあるので）
冗長化は不要（個人運用なので数日くらい止まっても困らない）
AZは一つで十分、ロードバランスもしない ※運用中のAZが長期間停止するなら別のAZで立ち上げする
データのバックアップは１日に１回
すでに2023年用に購入して利用中のSSL証明書をそのまま利用
バックアップはS3を利用

要件として大きいのはWindowsServer2012 (x64) からAmazonLinux2023 (ARM64)という部分です。
それでも大文字小文字と実行パスの２つ以外には問題にならない想定でしたので気にせず続行することにしました。

ディスクの容量はデータ抽出時の数値を参考に最初はちょっと余裕があるくらいでEC2を立ち上げました。
EC2のインスタンスのバックアップとしてEBSのサイズを指定してAMIが作れます。
ですが最初に決めたサイズよりも小さくするのが面倒なので大きくしすぎないようにします。

ちなみに、t4g.microは 2 vCPUs / 1 GiB の性能で、月々１１２５円（１４０円／ドル）くらいとなります。

インスタンスを起動してセットアップ

要件が決まったのでEC2インスタンスを起動してセットアップを行いました。
VPC/セキュリティーグループなどは今回のブログサイト運用専用に新規に整えました。
別の学習用のVPCがありますがそちらとは完全に分離して管理することにしました。

EC2操作用のSSH接続ソフトウェアはMobaextermを使っています。

ソフトウェアのインストール
nginx, php-fpm (拡張機能), mariadb, cron (AL2023は非標準)
nginxの設定
apacheの設定ファイルはあったがパスが違うので新規に記述
mariadbの設定
mysqlの設定ファイルはあったがメモリ使用量が700MB近くになっていたので新規に記述
php関連の設定
PHPはphp-fpmに変わっているため新規に記述
loglotateの設定
ログの肥大化を抑えるために対応、（７日間まで）
cronの設定
S3へのバックアップを毎日行う＆自動化
journalのログのリミット設定
無制限だとディスク容量が足りなくなるかもなので30MBくらいに制限
dnf/yumのキャッシュを削除
そこまでディスク容量確保にならなかった・・・

今回、ウェブサーバーのソフトウェアをapacheからnginxに変えたので設定ファイルはあまり参考になりませんでした。
Apacheは機能が多いためか設定も多くて設定項目を探すのが大変ですが、nginxは主要ファイルが3つのみで行数も少ないのでシンプルです。

MySQL -> MariaDBへの置き換えはメモリ使用量の差が多きすぎるので別の開発で使っているmariadbの設定を元に調整しました。

パフォーマンス重視ではなくてメモリ使用量を優先しての設定です。
Linux開始後の各ソフトウェアが起動した状態でメモリ使用量は全体で300MB以内くらいになっています。

nginx/php-fpm/mariadbはメモリ使用量を見つつ、パフォーマンスが極端に下がらないように注意しながら設定ファイルを作りました。
mariadbが400MB前後、nginx+php-fpmが300MB前後くらいを想定しておくことで1GiBのメモリで足りる想定です。

一番重たい処理のデータベースのバックアップ処理を行ってもmariadbが20%以下なので400MBを超えることはなさそうです。

その他、インスタンスのスペック的に 2 vCPUs なので、nginxの設定ファイルでは大量にリクエストを受けすぎないくらいにしました。
１クライアントに占有されるのも困るので同時接続制限や帯域制限なども行ってあります。

後は運用中にトラブルになりやすいログ管理も事前に対策してあります。
あとは、ディスク容量の確保に不要なキャッシュなども削除しました。

バックアップデータの復元と調整

抽出したデータをEC2へコピー

MariaDBへデータベースのバックアップをリストア
データベースのアクセス用アカウントの追加
ついでにバックアップ・メンテナンス用のアカウントも追加
PHPのスクリプトのコピー
ブログのデータのコピー（バイナリデータ）
SSL証明書のデータのコピー

このタイミングではひとまず、オンプレミス運用で利用していたPHPのスクリプトをそのままEC2へアップロードしました。

ソースコードやデータのコピーに関してはWinSCPというソフトウェアを使っています。

Linux用にスクリプトなどを調整

PHPのスクリプトをLinuxに合わせる
大文字小文字のファイル名やディレクトリ名に相違がないか確認
ある程度の気づく範囲で修正しつつ動作テストの際にその都度直すくらいのチェックのみです。
データベース内にWindowsの絶対パスがないかチェック
パスがWindowsようになっているレコードが１つだけあったのでupdateのsqlとreplase関数でクエリで置き換えました。

PHPソースコードはローカル(Windows11)上でVSCodeでフォルダを開いて一通り修正しました。
修正箇所が見つかったらローカルで直してEC2へアップロードを行うという手順の繰返しです。

PHP8系へのアップデート

PHP5系からPHP8系へのアップデートでのトラブルも少しありました。
一部のPEARでインストールするソースコードがPHP8対応されていないようでこの辺りは自前で直す必要がありました。
セキュリティー的にどの機能とは言えませんが以下のようなエラーがありました。

文字列の最初の文字を得るための$val{0}という書き方が7.4で削除
$val=&new class()とクラス生成を変数に入れる機能が7.0で削除

どうやらすでにメンテナンスされていないものなので使い続けるのは良くなさそうですね。

その他、オリジナルフレームワークに関してはPHP8にしたから実行できないというのは１つだけでした。
そもそもオンプレミス運用の時点で動いていなかった可能性が高そうなコードではありましたが・・・

動作テスト

主に以下のような内容を確認しました。

会員制のブログサイトなのでログインできるか、登録したブログの履歴が見えるか
リンクから別のページに移動できるか
オンプレミス運用中のウェブサイトと同じ挙動であるか
PHPやnginxのログを見てエラーや警告がないか

もうほったらかしですが私自身が更新していたブログサイトのデータが残っているのでこちらを元に動作確認を進めました。
以下の画像はブログに投稿した画像一覧表示を行う機能の動作確認をしていた時のものです。

ブログ投稿サイトなので画像が新規にアップロードできるかやブログ記事に画像が張り付けられるかなどを確認しました。

PHPスクリプトの設計として、ルートディレクトリが一致すればWindowsでもLinuxでも相対的にアクセスするようにしていました。
そのため、大文字小文字のLinux特有の問題がなければ基本的には動作すると考えています。
実際ほとんどの動作は問題ありませんでした。

正しく動作していなくて戸惑ったところとしては一部の機能が有効になっていなかったところです。
nginxとphpの設定ファイルを新しく作っているウェブサイトの設定を参考にしたために起きていた問題です。
具体的にはセッション管理処理とMariaDBのAutoCommitの設定ですね。

新しく作っているウェブサイトはRedisでセッション管理しているのでごっそり抜けていました・・・　

運用テスト

家族が更新しているウェブサイト

こちらはいつも使っている人が正しく使えるかどうかの確認してもらう段階です。
ざっとは問題なさそうな感じでしたので数日ほど様子見て問題がなければ完全にクラウド移行完了となりそうです。

時々はメモリ使用量をみたりしていますが、ソフトウェアが異常終了するような現象はなさそうです。

ディスク容量の調整

一通りの環境移行が終わったところでディスク容量が50%を超えていました。
初期は50GBでしたがOSやソフトウェア関連のアップデートで25GB以上になってしまったので、60GBにしました。

作業途中にAMIを作ってバックアップで効率アップ

ソフトウェアのインストールやデータのコピーなど時々時間が掛かる作業があります。
この時にある程度のめどが立ったタイミングでAMIを作っておくと何かしらのミスで戻したいというのがスムーズに行えます。

ディスク容量変更もAMIから起動する際にEBSの容量を増やして起動、Elastic IPを関連付けしなおすだけというはとっても楽ですね。

モニタリングで異常がないかチェック

１日動かしてみてのモニタリングの様子ですがスパイクはあれど大きな問題はなさそうです。
S3への１回目のバックアップでネットワーク送信料が大きく跳ね上がっていますが以降はスパイクも少ないので通信量による料金過多の心配も少なそうです。

クラウド化する前からBotなどで大量のリクエストが来た際のネットワーク帯域の使用量が懸念でした。
モニタリングの状況を見る限り、異常なBotアクセスに対しては独自WAFがちゃんと動いているようです。

一時的に独自WAFを外したら10MB/sくらいになったので放置していたら結構な通信料金取られそうですね・・・（怖い）

S3へのバックアップ

S3とEC2のSSDとの同期処理でS3へバックアップを行ってみました。
初回アップロードなので25GBくらいありましたが１０～１５分くらいで転送が終了しました。

転送速度はAWS内部のネットワークということもあり1Gbpsに近い速度で転送されました。

オンプレミス運用からクラウド運用への引っ越し時のユーザーコンテンツの個数や容量は以下の通りです。

費用の発生状況

ひとまず１週間ほど動かした状態での料金発生状況は以下の通りです。
機能修正やS3の整理などで時々追加料金が発生していますが概ね運用コストとしてて初月は３千円程度くらいになりそうです。
EC2からS3への初回のバックアップの転送料金が＄１、S3のゴミデータの整理などで＄５ほど発生しています。
※コストリストにEFS・ECR・CloudFront・SNSなどの他のサービスも記載されていますがこれらは別の検証で発生している料金となります。

ほぼ落ち着いた状態での約１か月の費用

　
１日＄１未満となっています。
消費税などが月初めに加算されますので最終的には１日＄１ちょいといったところでしょうか。

Budgetsは1週間に1度、全体の費用の通知をAWSからメールで送っているのでその費用です。
AWSにログインしなくても発生している料金がわかるようにしておくのはかなり大事です。
後は、意図しない料金発生などを検知できるように自分の予算に合わせたアラート機能なども活用するとさらに安心できます。

あとがき

そろそろオンプレミス運用からクラウド化しようと考えたのは４～５年前ですが当時は t2.micro か t2.small で悩みました。
ですが、自宅のWindows Server 2012が 8スレッド/16GiBでメモリが3.7GBほど常用している状態のため、Windows運用だと t2.small でさえ厳しかったです。
Linux運用に踏み切れていればよかったのですが、当時はそこまでLinuxの知識が多いとは言えなかったのもあり断念しました。

今回、初めて自宅（オンプレミス運用）のWindows ServerからAmazon Linux 2023（クラウド）へ移行しました。
思ったよりも短時間で対応ができまして、実時間２０時間くらいでクラウド化ができました。
自身で開発したものである点、AL2023/ARM64はDocker検証で学習済みだった点、Linuxの知識がついている点などが合わさって比較的にスムーズにできたのかなと思います。

クラウド化しちゃおう！って決めたのが土曜日で日曜日の深夜に作業終了。
そのままナレッジを書いているのですべてが完璧に動作しているのか不透明な部分はあります。
それでも今年の夏からは自宅サーバーのメンテナンスをしなくても問題ないし、空調管理もしなくて良いのは気持ち的にとても楽ですね。

これでオンプレミス運用用のサーバー購入費の予算を考えなくても良くなりました。
省電力な小型PCでも用意してバックアップサーバーも新調できそうです。

お古のPCは物によってはリサイクル料金が掛かったりします。
個人でのオンプレミス運用というのは意外と面倒なことが多いな改めて思います。

PCのリサイクルについて

私の場合はサーバーについては正規ショップで購入しているのでショップで引き取ってもらえそうです。
自作PCやお古のBTOのPCなどはリサイクル料金が掛かるかもしれませんが致し方ないですね。

一般公開用インフラ　実践編１「オンプレミスからクラウドへ：小規模ウェブサイト運用」

まえがき

個人でブログサイトを運営中

OSサポート終了＆機材の老朽化

クラウドを検討することに

諸注意

目次