どうもアクトインディ Advent Calendar 2015 の 18 日目の記事になります！本日の担当は namikata です。今日は「AWS で WEB サービスを運用する際に知っておいたら少しは役立つこと」をつらつらと書いて行こうと思います。テーマは大きいのですが、記事の内容は、運用していて分からなかったことを AWS の Support に質問して、回答をもらったのをメモしていた程度のものなので、しょうもない内容も多いですが、きっと為になる内容も含まれていると信じて、記事にまとめたいと思います。

すでに変わっている内容もあるかもしれないです。その時は指摘いただければ

料金編

リザーブドインスタンスは積極的に活用する

リザーブドインスタンスは、なるべく無駄が発生しないように良く考えられているサービスなので、コストを減らしたい場合は積極的に利用していきましょう。

覚えておいたほうがいいのは、

リザーブドインスタンスはインスタンスを買うのではなく、利用できる権利を買う。ということ。
一括おまとめ請求をしていた場合は、買ったリザーブドインスタンスはアカウント間で適用される
異なるリージョン、Availability Zone には適用できない

例1）

アカウントA : m3.medium x 1 起動
アカウントA : m3.medium x 1 のリザーブドインスタンスを購入

アカウントA m3.medium : 自動的にリザーブドインスタンスの権利が適用される

↓

アカウントA m3.midume を削除する : リザーブドインスタンスの権利はあるが、適用するインスタンスがないからもったいない

↓

アカウントA m3.medium を新しく立ち上げる : 自動的にリザーブドインスタンスの権利が適用される

例2）

アカウントA : m3.medium x 1 起動
アカウントB : m3.medium x 1 起動
アカウントA : m3.medium x 1 のリザーブドインスタンスを購入

アカウントA とアカウントB は一括おまとめ請求をしている

↓

アカウントA m3.medium : 自動的にリザーブドインスタンスの権利が適用される

↓

アカウントB m3.medium : リザーブドインスタンスの権利は1つしか買っていないので、オンデマンド料金

↓

アカウントA の me.medium を m3.large にスケールアップする : m3.large はオンデマンド料金

↓

自動的に m3.meduem のリザーブドインスタンスの権利がアカウントB の m3.medium に適用される

EC2 編

AMIの取得中にインスタンスを起動しても問題ない

・Question

AMIを取得するために一度インスタンスを停止してからおこなっているのですが、起動するタイミングは、AMI取得中に行っても問題ないでしょうか？

・Answer

はい、取得を実施頂いたのち、AMI取得中に EC2インスタンスを起動頂いても問題ございませんのでご安心ください。残念ながらご質問への説明はございませんが、該当する機能のドキュメントをご紹介いたします。ご参考になれば幸いです。

Amazon EBS-Backed Linux AMI の作成 http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html

EC2 でメールの大量配信をする場合は、Eメール制限の解除が必要

EC2 インスタンスにメールサーバーを立てて、メールを配信する場合、メール配信に利用する elastic ip は事前申請が必要。申請出さずに配信しようとしても、配信制限がかけられていて、全然メールが送れない。

手順としては

ipアドレスのブラックリストを調べられるサイトで、メールで利用しようとしているipアドレスが、既にブラックリストに認定されていないかチェックする
問題なければ、AWS に申請を出す

期間は余裕を持って1ヶ月ぐらい考えておいたほうがよさげ？（実際は申請から1,2週間ぐらいで認定されたような気がする）

複数のIPを複数のENIを使った場合と単一のENIで使った場合とでパフォーマンスの違いは出ない

・Question

複数のIPを複数のENIを使った場合と単一のENIで使った場合のパフォーマンスの違いが出るかどうかについてご教示いただけないでしょうか

・Answer

複数のIPを複数のENIを使った場合と単一のENIで使った場合とでパフォーマンスの違いはございません。ENIについては仮想NICとなりますため、ENIを複数設定しても実際の物理NICが設定したぶん割り振られるわけではなく、帯域の増強/耐障害性の増加といったメリットはございません。EC2 では、1 台の仮想サーバーホストを複数のインスタンスで共有してご利用頂いております。ネットワーク帯域については 1 台の仮想サーバーホストの持つ帯域を複数のインスタンスで共有する形となりますので、インスタンスに対して複数の ENI を割り当てたとしても、インスタンスのネットワーク帯域幅増加に結びつくわけではありません。詳細については下記ドキュメントをご参照ください。

I/O リソース - Amazon Elastic Compute Cloud http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/instance-types.html#IOResources

外部サイトとなりますが、下記もご参考になれば幸いです。

■[AWS][VPC]ENIについて考えてみた http://d.hatena.ne.jp/j3tm0t0/20120410/1334086123

S3 編

S3 のバケットのコピーの進捗は管理画面では確認できない。AWS CLIを使って進捗を確認する

・Question

S3のバケットをバックアップする目的で、新規にバケットを作成し、既存バケット内のディレクトリ毎コピーを実施しました。手順としては、以下のドキュメントを参考にし、「Copy」のActionで実施しました。 http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/gsg/CopyingAnObject.html http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/UG/MakingaCopyofanObject.html

この際、途中でポップアップ画面が立ち上がり、「Reload」の文言があったため、「Reload」を押下しました。その後、AWS管理コンソール画面がリフレッシュされ、Transfersの進行状況が消えてしまいました。進捗状況が分からなかったため、ディレクトリを見ていましたが、Copy自体が動いていないように思われたため、一度バケットを削除し、再作成してからコピーを行いました。そこで、再発防止を検討しているのですが、以下3点について、何か方法はありますでしょうか？

上記のような「Reload」となるのは何が原因でしょうか？
AWS管理コンソール以外でS3のCopy状態を確認する方法 ※AWSドキュメントを読む限り、ブラウザを閉じると進行状況の確認ができない旨は認識しています。
AWS管理コンソール以外のコピー方法

・Answer

CopyをAWS管理コンソールで実施し、その進捗をAWS管理コンソール以外でご確認いただくことはできません。

3.AWS管理コンソール以外のコピー方法

AWS CLIのご利用はいかがでしょうか。オブジェクトが増えた場合も1つのコマンドでコピーができ、また、進捗につきましてもご確認いただけます。

AWS コマンドラインインターフェイス http://aws.amazon.com/jp/cli/

cp http://docs.aws.amazon.com/cli/latest/reference/s3/cp.html

コマンド実行例 aws s3 cp s3://mybucket/ s3://mybucket2/ --recursive ※再帰的にmybucketバケットからmybucket2へコピーする

MySQL の RDS 編

オンライン稼働中の RDS でリードレプリカを作成した場合、マルチ AZ であればサービス断は発生しない

オンライン稼働中のDBインスタンスについて、リードレプリカを作成した際、サービスの瞬断等は発生するかをご教示の程よろしくお願いいたします。リードレプリカの作成により、DBの停止、再起動等が発生し、サービスが瞬断または停止することを懸念しております。

マルチ AZ 配置の場合は、通常スタンバイのスナップショットから作成しますため、アクセス断などは発生致しません。シングル AZ 配置に関しては、スナップショットを撮る間、ソース DB インスタンスに軽度の入出力停止が発生します(入出力の一時停止は、通常 1 分程度です)。

スナップショット取得中にDB定義を変えても問題ない

・Question

RDSのMysqlのテーブル定義を変えようと思ってます。変える前にスナプショットをとろうと思っているのですが、スナップショットの取得が完了するまえに、テーブル定義を変えることに何かリスクはあるかご教示いただけないでしょうか。

・Answer

DB スナップショットは、瞬間的に I/O を停止し、整合性のあるスナップショットを取得したのち、I/O を再開し、その後当該スナップショットは自動でS3 へ保存される動作となります。スナップショット取得中に操作をされましても特に問題はございませんが、I/O が停止されている最中に操作をされますと、その操作はロストするわけではなく再開後に適切に処理されますので、表面上はサービス断ではなく遅延として現れることとなります。

バッチサーバーなど、大量の insert や update を行うインスタンスと RDS の Availability Zone は同じにする

元々、バッチ処理を行うインスタンスと RDS は同じ Zone に配置していたのですが、意図せず RDS がフェイルオーバーして、異なる Zone になってしまったことがあり、結構なバッチ処理の遅延が発生してしまいました（処理の量によって影響は変わると思いますが、バッチの実行時間が3倍ぐらい増えた）。耐障害性の観点からも、バルクインサートなどを活用して、異なる Zone でもサービスが維持されるように努めるべきですが、同じ Zone に配置できるならしておいたほうがいいです。

RDS のメンテナンスで再起動が入る場合は、 Multi-AZ を利用している RDS はフェイルオーバーする可能性がある

メンテナンスにより、Multi AZを利用している RDS はフェイルオーバーされる可能性はありますか？

はい、メンテナンスの際に Failover される可能性がございます。メンテナンス後に RDS の状態をご確認頂き、必要な場合には Failover を実施頂くようお願いいたします。

「Reboot With Failover?」を有効にしてRebootを行っても、間隔が短いとフェイルオーバーしない

・Question

「Reboot With Failover?」にチェックを入れRebootを4回行ったところ、Availability Zoneが変更されたのは1回のみで、他の3回は変更されませんでした。「Reboot With Failover?」にチェックを入れてRebootすることで、 Availability Zone を変更することができる認識でいたのですが、他に条件が必要になりますか？

・Answer

ご使用の DB インスタンスでフェイルオーバーに失敗したのは、短時間で複数回 Reboot を実行したためとなります。RDS の仕様として、短い間隔で複数回 Reboot (Reboot With Failover) を実行致しますと、続けて指示されたフェイルオーバーは実行されない場合があります。フェイルオーバーが実行されなかった場合、マネジメントコンソールの Events に下記のエラーメッセージが表示されます。

　--- 　Abandoning user requested failover since a failover recently occurred on the database instance 　---

この Event が発生した場合、しばらくお待ちいただいた上で、再度お試しください。

・Question

　RDS の仕様として、短い間隔で複数回 Reboot (Reboot With Failover) を実行致しますと、続けて指示されたフェイルオーバーは実行されない場合があります。

こちら、「短い間隔」について目安とする時間が分かればお伺いしたいのですが、どれぐらいの間隔を空けて実行するのが望ましいでしょうか。

・Answer

こちらは残念ながらご案内できる情報がございませんので以下は参考情報となりますが、当方の手元環境にて実施した際には、10分から20分程度空けることで再度の Failover が可能でございました。なお Failover が成功したかどうかは、Events の出力でご確認頂けます。

フェイルオーバーした際、管理画面の Availability Zone の反映には時間がかかることがある。ログに failover complete が出ていれば、フェイルオーバーは完了している。

・Question

「Reboot With Failover？」にチェックを入れ、RDSをRebootしたところ、「Events」のログには、数分でfailoverのcompleteが表示されましたが、Instance画面の「Security and Network」のAvailability Zoneの表示が更新されるのに30分程度かかりました（画面のリロードは何度か試しております）。再度「Reboot With Failover？」にチェックを入れ、RDSをフェイオーバーさせる作業を行いたく、Eventsログにfailoverのcompleteが表示されていれば、フェイルオーバーの処理が完了していると考えてよいのか教えていただけると助かります。

・Answer

ファイルオーバー完了の確認は、Event で「Multi-AZ instance failover completed」と表示されれば、ファイルオーバーは完了しているという認識となります。