Lightsail に久しぶりに新しいインスタンス（Ubuntu 24.04）を作ったら SSH できなくなっていた。
https://docs.aws.amazon.com/ja_jp/linux/al2023/ug/ssh-host-keys-disabled.html
このあたりを参考に色々やってみたけど解決せず。
認証鍵を作り直しても、SHA1を有効にしてみても（当たり前だけど…）変化ない。うーん。
RSA2認証鍵の署名方式が原因だった。SHA2-512に設定変更すればOK。
Lightsailインスタンス側がSHA2-256を弾くようになったってこと…？
AWSに独自ドメインを設定したときのメモ。
Amazon Route 53 はクラウド上でDNSサーバを提供してくれるウェブサービス。
ただし今のところ日本語化されていないので、操作性にちょっと難あり。
（当たり前だけど従量課金されるので注意してね）
まずAWS管理コンソールにログイン。
サービス一覧から「Route 53」を選択。
「DNS Management」に入り、「Create Hosted Zone」を選択。
「Domain Name」に取得済みドメインを入力。sample.comなど。
「Comment」は適当に。 「Type」は「Public Hosted Zone」。
「Create」ボタンを押すとゾーンが作成される。
次にレコードを作っていく。
メニューから「Go To Record Set」を選択。
デフォルトで NSレコード と SOAレコード が作成されている。
（コレをいじくるんじゃねぇぞ、とチュートリアルに書いてあるので触らないでおきます）
「Create Record Set」をクリック。
「Name」にサブドメイン名。 まずは空白でよい。
「Type」はIP-V4。 V6にするときが来るんだろうか・・・。
「Alias」は「No」、「TTL」はデフォルトのままで。
「Value」に取得済みの Elastic IP を入力。
「Routing Policy」は「Simple」に。 他のは課金コース。
「Create」ボタンを押すとAレコードが作成される。
ここまでで名前が引けるようになっているはず。
諸事情でAWSからレンタルサーバに移行したので、その顛末を記しておく。
地方の小さなプロダクトで、小規模なブランドページを企画した。
予算も限られているということで、ほかのプロダクトも展開していたAWS上で構築。
単発の品物だったので、運用期間は数年程度を予定していた。
あまりないケースかもしれないが、低予算で目標達成したらごほうびがもらえる、とイメージしてもらいたい…。
単なるWebサイト（Wordpress）ということで、比較的非力なEC2サービスをチョイスした。
独自ドメインを一応とり、サービスイン。
しばらくはぽつぽつとアクセスがある程度で、とくに問題なかった。
とある時期を堺に、使用量がじわじわ上がってきた。
ありがたいことに多少話題になったようで、アクセス数が上がってきたらしい。
で、そうなってくるとAWS特有の「使ったぶんだけ課金」というのが響いてくる。
アクセスが大いに越したことはないのだが、実験的な側面もあり予算が決まっているのがネックであった。
このままいくと予算をぶっちぎっちゃうカモ…？
ec2サービスの利用料を圧縮するために、しばらく経ってからリザーブドインスタンスを導入した。
その名の通り、EC2の使用を予約し、利用料を値引きしてもらうシステムである。
（今思えば、数年運用する計画だったのだから最初からやっておけば良かったのだが…）
そのときはEC2の利用料が大半だったので、予算内に収まるよう調整できた。
よかったよかった、これで計画通り、実験的にも成功といえそうだ。
…ところが、ここからさらにハネてしまい、EC2利用料でなくデータ転送量が料金の大半を占めるようになってしまった。
しかも、ピークタイムになるとアクセス過多のため、メモリ不足でapacheかmysqlが落ちることも。
完全に当初の想定アクセス数を上回ってしまう状況になってしまった。（本来ならありがたいことだが…）
さて、当座の対処としては、apacheとmysqlが落ちないようにしなければならない。
調整を入れたり、SWAP領域を多めに確保するなどしてみた。
スワップファイルの設定については公式サイトが詳しい。
スワップファイルを使用して、Amazon EC2 インスタンスのスワップ領域として動作するようにメモリを割り当てる
なんでSWAP領域がないねん…と思ったけど、ディスクIOで課金される以上、AWS側としては勝手にSWAP領域を設定するのはマズいやろ、ということらしい。必要なら覚悟の上で自分で設定してね、というスタンスなのだろう。
公式がわざわざ「注意: スワップ領域は、エフェメラルストレージのインスタンスストアボリューム上にのみ作成することをお勧めします。」と書いてあることに注意していただきたい。
エフェメラル（ephemeral：一時的な）ストレージは再起動するたびにクリアされるストレージのことである。
そのかわり、ここへのディスクアクセスについては課金されない。
前述したとおり、今回チョイスしたEC2インスタンスタイプは低価格帯であったため、インスタンスストアボリュームが存在しなかった。
ディスクアクセスによって課金されることを知りながら、スワップファイルを高価なEBS上に作成しなければならない、このストレス！
Apacheの調整とスワップファイルを設定したことで落ちなくはなったが、ディスクIOで予算を使い切ってしまう未来しか見えない。
なんらか対策が取れるのかもしれないが、それをやってる時間がないくらい、データ転送量もえらいことになっていたのだ。
多数使用していた画像を圧縮してみたりしたが、仮にもブランドサイトなので限界がある。
ローコストでスタートできる、というウリでAWSをチョイスしたのだが、（うれしいことに？）アクセス過多で負荷が高まり、結局立ち行かなくなってしまった。
無難に安く仕上げるつもりが、クラウド破産に怯えるハメに。なにやってんだ？？(ヽ´ω`)
こういうとき予算があればインスタンスタイプを変更することで対応できるのだろうが、今回は諸事情でそうはいかなかった。
リザーブドインスタンスも無駄になるしね…。
というわけで、「一日の」データ転送量に比較的余裕のあるレンタルサーバに移行することにした。
一日の、というのがミソで、くだんのWebサイトではスパイクはそれほど発生しておらず、一日あたりで見てみれば十分おさまる範囲であったのだ。
じっくり考えている余裕はあまりなかったので、とりあえずさくらのレンタルサーバとロリポップの2件に絞った。
値段は2019年12月調べ。
ライトプランは131円からと、とにかく安い。
スタンダードプラン（月額524）
一日あたりの転送量：80GB
プレミアムプラン（月額1571）
一日あたりの転送量：120GB
さくらの間隙を縫うようなプラン設定。
ハイスピードだとストレージがSSDでリッチ。
スタンダードプラン（月額500～）
一日あたりの転送量：100GB
ストレージ：HDD
ハイスピードプラン（月額1000～）
一日あたりの転送量：100GB
ストレージ：SSD
あれ…すっげー安い。
どちらにしたかはここではあえて申し上げますまい。
とにかく、今回のケースにおいてはAWSよりレンタルサーバのほうが遥かに安く上がった、ということである。
そのほか、各種アップデートを気にしなくてよくなった。
プロセスが落ちることを気にする必要もない。
VPSのように自由度はないが、「任していい部分」を任せられるのが楽だ。
さらにおまけでいうと、独自ドメインのメールアドレスが作れたのがお客さんにやたらとウケた。
メールサーバまで構築するのはちょっと合わなかったので作ってなかった。
（最初いらない、と言ってたんだけど…）
不勉強が招いたこと＆使い方が合わなかっただけで、AWSをディスる意図はない。
実際にやってみて知見を得、ここには記せないことも色々体験できたのは良かった。
AWSは
に使うべきかなと思った。
常時稼働の開発サーバの運用コストを下げたい。
オンデマンドでなく、あらかじめ枠を買っておくリザーブドインスタンスを購入すれば、運用コストを抑えられるらしい。
というわけで調べた。
2019年8月時点、開発サーバで使用している「東京リージョン、t3.nano」で試算。
金額はあくまで参考値。
オンデマンド（随時）
$0.0068×24時間×365日＝$59.568(≒6,307.06 円)
リザーブド（予約）
$0.004×24時間×365日＝$37.8432(≒4006.84円)
おお、開発サーバ1台で年間SSD一個買えるくらい浮くんじゃないの？
より性能が高い本番サーバであれば、すっげー浮きそうだ。
（そっちは手が出せないけど…）
オンデマンド
自由。いつでも止められるし変更できる。
思ったより負荷が高いので拡張する、といったことが柔軟にできる。
クラウドコンピューティングのメリットを最大限享受できる。
時間単価が割高。
リザーブド（スタンダード）
割引が適用され、時間単価が割安になる。
サーバが安定期に入ってランニングコストを抑えたいようなときに使える。
「枠」を購入するので、使用を止めても料金がかかる。
リザーブド（コンパーチブル）
オンデマンドとリザーブドの中間。
追加料金を支払えば、予約内容を拡充できる。
（「拡充」なのがミソ。縮小することはできない）
そこそこ自由＋そこそこの割引。
EC2におけるリザーブドが適用されるのは、（当たり前だが）EC2の使用料金だけだ。
実際にはデータの転送量やストレージの使用量もかかってくる。
割引は40％くらいなので、開発サーバで一日15時間以内の稼働であれば『こまめに停止→起動』したほうが安くつくかもしれない。
デスマーチだとこういう面でも損だゾ☆
EC2コンソールから「リザーブドインスタンス」→「リザーブドインスタンスの購入」と進む。
検索条件にプラットフォームやインスタンスタイプなどできるだけ詳細に入れ、「検索」ボタンを押す。
支払い方法は
となっている。もちろん全額前払いが一番お得である。
インスタンスタイプを間違えないように！
購入に成功したならば、リザーブドインスタンスのところに表示される。
ec2コンソールから確認できる。
「レポート」→「EC2リザーブドインスタンス（RI）の仕様状況レポート」と進む。
適用されていれば、使用状況が表示される。
表示されない場合、チェックする項目。
もしインスタンスタイプを間違えていたら、EC2インスタンスの方をそれに合わせるか、枠を売るしかないらしい。
WordPress 5.1 のアップデートで、php5系が怒られるようになった。
ので、これを機に httpd2.2 -> httpd 2.4 、php5 -> php7 にアップデートすることにした。
環境：Amazon Linux
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
# まずアンインストール sudo yum remove httpd sudo yum remove mod_ssl sudo yum remove php # httpd24, php72 をインストール sudo yum install httpd24 sudo yum install mod24_ssl sudo yum install php72 # ssl取り直し（すでにやっていれば基本不要） certbot-auto certonly --webroot -w /var/www/html -d sample.com --email sample@gmail.com -n --agree-tos --debug # ssl設定見直し（必要な場合） sudo nano /etc/httpd/conf.d/ssl.conf # ssl.conf 内 証明書ファイルのパスを変更（必要な場合） SSLCertificateFile /etc/letsencrypt/live/sample.com/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/sample.com/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/sample.com/chain.pem # httpdサービス再起動 sudo service httpd restart |
mod_ssl だとコンフリフトが発生する、mod24_ssl がハマった…。
mod_ssl24 じゃないのね…。
WordPress をバージョンアップしたらパーマリンクが文字化けする件。
httpd2.2系からhttpd2.4系にバージョンアップした影響だった。
mod_rewrite の設定が初期化されたため、URLの変換がうまくいかなくなっていたらしい。
というわけで再設定する。
|
1 2 3 4 |
<Directory "/var/www/html"> Options -Indexes +FollowSymLinks AllowOverride All </Directory> |
AllowOverride を All にすればOK。
ついでにディレクトリ内容の一覧表示をしないように修正。
ほんとはパーマリンクをスラッグとかにすべきだったけど、もう記事書いちまったからね…
AWS上で運用している Aipo のカレンダーに2019年の休日設定を行う。
管理画面などでできそうな感じだったが見当たらない。
調べてみると、どうもテキストファイルで管理しているようだ。（なんで？）
というわけで、SSHなどでログインしてテキストファイルを編集し、サービスをリスタートする、という手順になる。
ちなみに環境は Amazon Linux + Aipo8.1.1.0 。
|
1 2 3 4 5 |
cd /usr/local/aipo/tomcat/webapps/ROOT/WEB-INF/conf/ sudo cp ./holidays_default.properties ./holidays_default.properties.20190206 sudo nano ./holidays_default.properties sudo /usr/local/aipo/bin/shutdown.sh sudo /usr/local/aipo/bin/startup.sh |
「スケジュール」機能を確認して、反映されているか確認する。
ちなみに、現在わかっている2019年の祝日は以下のとおり。
元日,2019-1-1
成人の日,2019-1-14
建国記念の日,2019-2-11
春分の日,2019-3-21
昭和の日,2019-4-29
国民の休日,2019-4-30
即位の日,2019-5-1
国民の休日,2019-5-2
憲法記念日,2019-5-3
みどりの日,2019-5-4
こどもの日,2019-5-5
振替休日,2019-5-6
海の日,2019-7-15
山の日,2019-8-11
振替休日,2019-8-12
敬老の日,2019-9-16
秋分の日,2019-9-23
体育の日,2019-10-14
即位礼正殿の儀,2019-10-22
文化の日,2019-11-3
振替休日,2019-11-4
勤労感謝の日,2019-11-23
意地でも vi でやる人がいるけど、nano の方が使いやすいと思うなあ。
awsインスタンスの各種ログをダウンロードする。
僕がよくやるやり方。みんなどうやってるんだろう…。
以下、sshで作業
cd /var/log/
sudo chmod 755 ./(ログファイル名)
httpdの場合は
sudo chmod 755 ./httpd/*
僕が使用している RLogin の場合は、ファイル→SFTPファイルの転送
sudo chmod 600 ./(ログファイル名)
sudo chmod 600 ./httpd/*
exit
mysql の root のパスワードを忘れたとき。
（別にAWSに限らないけども）
sudo service mysqld stop
sudo nano /etc/my.cnf
[mysqld] セクションに「skip-grant-tables」追記
sudo service mysqld start
mysql -u root
|
1 2 3 |
use mysql; UPDATE mysql.user SET Password=PASSWORD('新しいパスワード') WHERE User='root'; flush privileges; |
sudo nano /etc/my.cnf
「skip-grant-tables」を消す か コメントアウト
sudo service mysqld restart
mysql -u root -p
→設定したパスワード
Amazon の AWS 上で試験運用していた Aipo から、いつの間にかメールが送信されなくなっていた。
SMTPサーバは外部のSMTPサーバを指定している。
ログ等確認してみたがそれらしきものは無かった。
こないだまで送信されていたので、設定が原因とも考えにくいし…。
もしかしてアップデートが原因？とか考えていたところで、あえてSMTPの設定を誤ったものに変更してみた。
すると、ちゃんとAipoのエラーログが吐かれる。
↓こういうのも目を通してみるが、SESとか使ってるわけじゃないし、外部のSMTPサーバだし、関係なさそうだけど…。
Amazon SES での E メール送信プロセス
https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/sending-email-with-ses.html
もう１件、こちらも参考にさせて頂いた。
https://cloudpack.media/11249
上記を参考に、拙い英語でEメールの緩和申請をしてみた。
数日で「解除したよ」というメールが届き、メールが送信されるようになった。
ってことでした。