AWS」カテゴリーアーカイブ

AWS(Amazon Route 53)に独自ドメインを設定する

AWSに独自ドメインを設定したときのメモ。
Amazon Route 53 はクラウド上でDNSサーバを提供してくれるウェブサービス。
ただし今のところ日本語化されていないので、操作性にちょっと難あり。
(当たり前だけど従量課金されるので注意してね)

  • EC2インスタンスは作成済み。
  • Elastic IP(グローバルIP)取得済み。
  • 独自ドメインは他レジストラで取得済み。

まず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からレンタルサーバに移行したので、その顛末を記しておく。

状況

地方の小さなプロダクトで、小規模なブランドページを企画した。
予算も限られているということで、ほかのプロダクトも展開していたAWS上で構築。
単発の品物だったので、運用期間は数年程度を予定していた。

あまりないケースかもしれないが、低予算で目標達成したらごほうびがもらえる、とイメージしてもらいたい…。

単なるWebサイト(Wordpress)ということで、比較的非力なEC2サービスをチョイスした。
独自ドメインを一応とり、サービスイン。

しばらくはぽつぽつとアクセスがある程度で、とくに問題なかった。

異変

とある時期を堺に、使用量がじわじわ上がってきた。
ありがたいことに多少話題になったようで、アクセス数が上がってきたらしい。

で、そうなってくるとAWS特有の「使ったぶんだけ課金」というのが響いてくる。
アクセスが大いに越したことはないのだが、実験的な側面もあり予算が決まっているのがネックであった。

このままいくと予算をぶっちぎっちゃうカモ…?

対策してみる

ec2サービスの利用料を圧縮するために、しばらく経ってからリザーブドインスタンスを導入した。
その名の通り、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をディスる意図はない。
実際にやってみて知見を得、ここには記せないことも色々体験できたのは良かった。

AWSは

  • すぐにインスタンスを作成でき、不要なときは停止できる開発サーバ
  • ある程度予算を確保できるプロダクト

に使うべきかなと思った。

リザーブドインスタンスを購入してEC2の運用コストを下げる

常時稼働の開発サーバの運用コストを下げたい。
オンデマンドでなく、あらかじめ枠を買っておくリザーブドインスタンスを購入すれば、運用コストを抑えられるらしい。
というわけで調べた。

料金

2019年8月時点、開発サーバで使用している「東京リージョン、t3.nano」で試算。
金額はあくまで参考値。

オンデマンド(随時)
$0.0068×24時間×365日=$59.568(≒6,307.06 円)

リザーブド(予約)
$0.004×24時間×365日=$37.8432(≒4006.84円)

おお、開発サーバ1台で年間SSD一個買えるくらい浮くんじゃないの?
より性能が高い本番サーバであれば、すっげー浮きそうだ。
(そっちは手が出せないけど…)

メリットとデメリット

Amazon EC2 リザーブドインスタンス

オンデマンド

自由。いつでも止められるし変更できる。
思ったより負荷が高いので拡張する、といったことが柔軟にできる。
クラウドコンピューティングのメリットを最大限享受できる。
時間単価が割高。

リザーブド(スタンダード)

割引が適用され、時間単価が割安になる。
サーバが安定期に入ってランニングコストを抑えたいようなときに使える。
「枠」を購入するので、使用を止めても料金がかかる。

リザーブド(コンパーチブル)

オンデマンドとリザーブドの中間。
追加料金を支払えば、予約内容を拡充できる。
(「拡充」なのがミソ。縮小することはできない)
そこそこ自由+そこそこの割引。

備考

EC2におけるリザーブドが適用されるのは、(当たり前だが)EC2の使用料金だけだ。
実際にはデータの転送量やストレージの使用量もかかってくる。

割引は40%くらいなので、開発サーバで一日15時間以内の稼働であれば『こまめに停止→起動』したほうが安くつくかもしれない。
デスマーチだとこういう面でも損だゾ☆

適用してみる

EC2コンソールから「リザーブドインスタンス」→「リザーブドインスタンスの購入」と進む。

検索条件にプラットフォームやインスタンスタイプなどできるだけ詳細に入れ、「検索」ボタンを押す。

支払い方法は

  • All Upfront(全額前払い)
  • Partial Upfront(一部前払い)
  • No Upfront(後払い)

となっている。もちろん全額前払いが一番お得である。

インスタンスタイプを間違えないように!

購入に成功したならば、リザーブドインスタンスのところに表示される。

リザーブドインスタンスが適用されているか調べる

ec2コンソールから確認できる。

「レポート」→「EC2リザーブドインスタンス(RI)の仕様状況レポート」と進む。

適用されていれば、使用状況が表示される。

表示されない場合、チェックする項目。

  • インスタンスタイプは合っているか?
  • 表示範囲が適切か?(デフォルトだとフィルタが先月分になっている。翌々日あたりから表示されるっぽい)

もしインスタンスタイプを間違えていたら、EC2インスタンスの方をそれに合わせるか、枠を売るしかないらしい。

WordPress5.1 のアップデートに伴って AWS で色々アップデート

WordPress 5.1 のアップデートで、php5系が怒られるようになった。

ので、これを機に httpd2.2 -> httpd 2.4 、php5 -> php7 にアップデートすることにした。

環境:Amazon Linux

手順を巻きで

mod_ssl だとコンフリフトが発生する、mod24_ssl がハマった…。
mod_ssl24 じゃないのね…。

 

WordPress をバージョンアップしたらパーマリンクが文字化けする件

WordPress をバージョンアップしたらパーマリンクが文字化けする件。

httpd2.2系からhttpd2.4系にバージョンアップした影響だった。
mod_rewrite の設定が初期化されたため、URLの変換がうまくいかなくなっていたらしい。
というわけで再設定する。

AllowOverride を All にすればOK。
ついでにディレクトリ内容の一覧表示をしないように修正。

ほんとはパーマリンクをスラッグとかにすべきだったけど、もう記事書いちまったからね…

AWS上の Aipo に 2019年の休日設定

AWS上で運用している Aipo のカレンダーに2019年の休日設定を行う。

管理画面などでできそうな感じだったが見当たらない。
調べてみると、どうもテキストファイルで管理しているようだ。(なんで?)

というわけで、SSHなどでログインしてテキストファイルを編集し、サービスをリスタートする、という手順になる。

ちなみに環境は Amazon Linux + Aipo8.1.1.0 。

  1. 設定ファイルの場所へ
  2. 念の為バックアップ
  3. テキストエディタで編集(nanoなど)
  4. Aipoサービス停止
  5. Aipoサービス開始

「スケジュール」機能を確認して、反映されているか確認する。

ちなみに、現在わかっている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インスタンスの各種ログをダウンロードする

awsインスタンスの各種ログをダウンロードする。
僕がよくやるやり方。みんなどうやってるんだろう…。

awsインスタンスにsshでログイン

以下、sshで作業

ログファイルディレクトリに移動

cd /var/log/

ダウンロードするためにパーミッションを変更

sudo chmod 755 ./(ログファイル名)

httpdの場合は
sudo chmod 755 ./httpd/*

SFTPでログをダウンロード(ソフトによる)

僕が使用している RLogin の場合は、ファイル→SFTPファイルの転送

パーミッションをもとに戻す

sudo chmod 600 ./(ログファイル名)
sudo chmod 600 ./httpd/*

おわり

exit

 

AWS mysql の root のパスワードを忘れたとき

mysql の root のパスワードを忘れたとき。
(別にAWSに限らないけども)

1.mysqld サービス停止

sudo service mysqld stop

 

2.起動パラメタ変更

sudo nano /etc/my.cnf

[mysqld] セクションに「skip-grant-tables」追記

 

3.mysqld サービス再起動

sudo service mysqld start

 

4.root でログイン

mysql -u root

 

5.パスワード再設定

6.起動パラメタ元に戻す

sudo nano /etc/my.cnf

「skip-grant-tables」を消す か コメントアウト

 

7.mysqld サービス再起動

sudo service mysqld restart

 

8.ログインテスト

mysql -u root -p
→設定したパスワード

AWS と Aipo の環境でメールが送れなくなった件

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

もう1件、こちらも参考にさせて頂いた。

EC2インスタンスからメール送信のための準備

上記を参考に、拙い英語でEメールの緩和申請をしてみた。
数日で「解除したよ」というメールが届き、メールが送信されるようになった。

AWSでのSMTPの利用自体、送信制限緩和が必要。

ってことでした。

AWS無料枠なのに請求が来た件

開発用Webサーバとして運用していたAWSアカウントから請求が来ていた。
無料枠内で運用してたのになぜ?? 明細を見てみると、

 Elastic IP address not attached to a running instance per hour

とある。どうやら、

IPアドレスがもったいねーから、インスタンス止めたらその分請求するよ。

ってことらしい。なんやそれ…。

確かに、開発用なので使用してないときはインスタンスを停止していた。

てことは、完全無料にしたけりゃElastic-IPの割当を使用しないか、ずっとインスタンスを起動しとけってこと?