Home > cloud > AWS

AWS Archive

AWS ELB に SSL 証明書を Management Console で設定する

この記事の所要時間: 27

Management Console で AWS ELB に SSL 証明書を 設定する方法です。

ここではすでに作成されている ELB(HTTP のみを Listen)に HTTPS します。新規で ELB を作成して、そのまま HTTPS を設定する場合も似た手順で設定できます。

対象の ELB の Listeners に HTTPS を追加

対象の ELB の Listeners に HTTPS を追加します。ここでは SSL Terminaion を利用するので、Instance 側は HTTP としています。
Load Balancer Protocol を選択すると SSL Certificate に「Select」というリンクができるのでこれをクリックします。

aws_elb_https_1

SSL 証明書を登録

SSL 証明書を登録する画面がポップアップで表示されるので、ここに発行された証明書を登録します。
中間証明書が複数ある場合、Certificate Chain に繋げて記載します。

aws_elb_https_2

「Save」ボタンをクリックすると証明書が登録されて、証明書を選択している状態になります。もう一度「Save」ボタンをクリックします。

aws_elb_https_3

追加した Listeners を登録

最後に追加した Listeners を登録するために「Save」ボタンをクリックします。これで HTTPS の Listeners と SSL 証明書が登録されたので、ブラウザ等から HTTPS でアクセスして登録した証明書を確認します。

aws_elb_https_4

証明書の変更、更新

証明書の更新などで Listeners に登録した証明書を変更する場合は、Listeners の SSL Certificate にて「Change」をクリックします。

aws_elb_https_5

ポップアップが表示され、証明書を選択する画面になります。ここでは一度登録した証明書を変更することができないので、Upload a new SSL Certificate を選択して、証明書の登録を行ない、新しい証明書を選択します。

aws_elb_https_6

ブラウザで完結するので楽

SSL証明書の登録や更新は、Webを運用をしていくと地味に続くタスクなので Management Console 上で誰でもできるのは楽です。さらに証明書の削除も Management Console でできるようになるとより良いですね。

  • コメント (Close): 0
  • トラックバック (Close): 0

SeleniumでAWS課金情報を取得する – JAWS-UG Osaka勉強会 第3回

この記事の所要時間: 147

Japan AWS User Group (JAWS-UG) – Osaka勉強会 第3回に参加してきました。

すっかり恒例になってきたJAWS-UG Osaka勉強会に参加してきました。今回も濃いセッション満載で楽しかったです。会場提供頂いたテレビ大阪さんありがとうございました。

せっかく参加するならということで、今回は Selenium を使って AWS の課金情報を取得して、Twitter で投稿するという内容でLTをやってきました。

SeleniumでAWSへの愛を叫ぶ

当日は真面目なものとそうでないものの2つ発表ネタを持って行っていたのですが、発表前にこちらにしました。

スライドを用意していましたが、このタイトルの解説を延々と書いているだけなので表紙だけアップしておきます:D

20110618_jaws_osaka_lt

SeleniumでAWS課金情報を取得する

やっていることは単純で、Selenium で AWSサイトにログインして、Account Actibityページで今月の課金(=愛)を取得、そしてそれをTwitterで投稿するだけです。

デモで使った Selenium テストケースのソースは以下です。(AWS アカウントのメールアドレスとパスワードは仮の値に変えています。)

ポイントは、課金情報をstoreTextで取得している点と、課金情報に含まれる単位($)をJavaScriptで削除している点ですね。

Seleniumを使えば、単純なスクレイピングならこれだけでできます。

テストケースをxUnitのソースに変換して、Selenium RCと組み合わせると、cronやJenkinsなんかで定期的に課金情報を取得することも可能です。

みなさんも愛を確認して、叫んでみて下さい:D

雑感

  • Beanstalk の PHP 対応が来るらしい!
  • Hadoop / EMR 分かりやすかったです。
  • Hadoop のデモは地味:D
  • 決戦に参加できて勝てて良かった!
  • 今回のLTは(自分以外)レベル高かったー。
  • おっぱいぷるぷる。

さあ、AWSをはじめよう! for PHPer

この記事の所要時間: 1116

春ということで、Amazon Web Services(AWS)をはじめてみませんか。

AWS盛り上がっていますね。2011年3月に東京リージョンができたことで、そろそろ触ってみようかなというPHPユーザの方も多いかと思います。

そんなあなたへ、AWSをはじめる際に役立つ情報をご紹介です。

1. AWSアカウントを新規作成して、EC2の利用申し込みを行う

まずAWSのアカウントを作成して、EC2の利用申し込みを行います。

手順については、AWSエバンジェリストの @KenTamagawa さんが書かれた以下の資料が参考になります。このとおりに進めていけば、おおよそ問題無いと思います。

進める中で自分が詰まった点は以下。

郵便番号、電話番号にはハイフンを

郵便番号、電話番号はハイフンが必要なので入力するようにして下さい。

書式は日本国内のもの、郵便番号8ケタ(ハイフン入り)、電話番号は12〜13ケタ(ハイフン入り)で大丈夫です。

電話にびびらない

EC2の利用申し込みでAmazonから電話がかかってくる場面があります。

実は、はじめてアカウントを作成して利用しようとした時は申込画面も英語版しか無かったので、英語な人から電話がかかってくるのかと思って、それはそれはびびっていました。気持ちの整理を付けるために2,3日かかった記憶があります:D

まあ冷静に考えてみれば分かりますが、人がかけてくるわけではなく、機械がかけてきます。電話を取るとアナウンスが流れるので、あとは画面に表示された暗証番号をプッシュで入力すればokです。(人がかけてくる場面を想像すると面白いですが:-p)

暗証番号を入力するとすぐに次の画面に遷移するので、これはこれで近未来な感じがして感動しました。

クレジットカードが必要

アカウント作成、EC2の利用申し込みは無料ですし、サービスを利用(EC2インスタンスを起動など)しない限りは費用は発生しませんが、クレジットカードの登録は必須となります。ご注意を。

2. EC2を触ってみる

では実際にブラウザでAWS Management ConsoleへアクセスしてEC2インスタンスを起動してみましょう。

この手順についても、@KenTamagawa さんが書かれた資料が参考になります。

補足としては以下の点あります。

SSHログインユーザ

このスライドのようにAmazon Linuxを利用する場合は「ec2-user」ユーザでSSHログインして下さい。他のOSで起動した際は、rootユーザでログインする場合もあるので間違えないようにご注意を。

SSHコマンドでログイン

SSHでログインするツールは、sshコマンドでも何でも良いです。その際はダウンロードした秘密鍵を -i で指定して下さい。

$ ssh -i /path/to/demo-key.pem ec2-user@PUBLIC_DNS_HOST

なお手元のMacではPublic DNSにあるFQDNを指定すると「ControlPath too long」というエラーが発生します。こういった場合は、Public DNSからIPを引いて、IP直で指定すればログインできます。(ただしIP変更が起こる場合があるので、可能ならFQDNでログインした方が良いです。)

$ dig ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com

xxx.xxx.xxx.xxx
$ ssh -i /path/to/demo-key.pem ec2-user@xxx.xxx.xxx.xxx

PHPのインストール

Amazon LinuxでPHPを利用するには、yumでインストールするだけです。

$ sudo yum -y install php

Amazon LinuxでインストールされるPHPのバージョンは、5.3.6です。(2011/04/12現在)

$ php -v
PHP 5.3.6 (cli) (built: Mar 29 2011 19:13:32)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

あとは必要に応じて、yumコマンドやpear、peclコマンドで追加していきましょう。

3. AWS SDK for PHP

まずAWSを利用する準備が整いました。

これからEC2インスタンス(サーバ)のセットアップをして、S3やEBS、RDSなどなどを活用していくと思うのですが、PHPerなら是非おさえておきたいのが「AWS SDK for PHP」です。

AWSはクラウド環境として多種多様なサービスを展開しているのですが、そういったサービスをAPIで操作することができます。例えばEC2インスタンスの起動、停止といった作業がどこからでもAPIで操作できるわけです。このAPIが揃っているのがAWSの特徴で、なかにはR53のようにAPIでのみ操作可能(AWS Management Consoleでは操作できない)なサービスがあるくらいです。

このAPIを活用すれば、独自の管理コンソールを構築することも可能で、実際そういったサービスも外部ベンダーから提供されています。

そんな便利なAPIなのですが、このAPIをPHPから簡単に操作できるようにSDKが提供されています。それが「AWS SDK for PHP」です。

3-1. 要件

AWS SDK for PHPは以下の環境で動作します。

PHPのバージョンさえクリアしておけば、あと必要なのはcURLくらいでしょうか。

ちなみに2.で構築したAmazon Linux環境のPHPでは、下記条件は全て満たされていました。

  • PHP5.2以上(5.2.14 or 5.3.x推奨)
  • SimpleXML / JSON / PCRE / SPL
  • cURL PHPエクステンション(HTTPSサポート)
  • file_get_contents() / file_put_contents() でファイルシステムを読み書きできる環境

3-2. インストール

AWS SDK for PHPはPHPソースで書かれたライブラリです。ダウンロードするだけで利用できますので、お好みの方法でインストールして下さい。

  • http://aws.amazon.com/sdkforphp からダウンロード
  • git
  • subversion
  • pear

ここではgitでインストールしています。

$ sudo yum -y install git  //git のインストール(git環境があれば不要)
$ git clone git://github.com/amazonwebservices/aws-sdk-for-php.git AWSSDKforPHP
$ ls
AWSSDKforPHP

要件やインストール方法はドキュメントがあるのでこちらを参考にして下さい。
=> Getting Started with the AWS SDK for PHP

3-3. 認証情報の取得

AWS SDK for PHPを実際に利用する際はAWSアカウントの認証情報が必要となります。

認証情報はAWSのWebサイトで取得できます。

まずグローバルナビの「アカウント」をクリックします。クリックするとアカウントのメニューが表示されるので下図のように「セキュリティ証明書」をクリックします。

セキュリティ証明書ページが表示されたら(もしログイン画面が表示されたらログインして下さい)、下図の「アクセス証明書」を表示します。ここにある「アクセスキーID」「シークレットアクセスキー」が認証情報となります。

3-4. サンプル

では実際にAWS SDK for PHP(以下、SDK)を使ってサンプルを作ってみます。

ここでは全リージョンのEC2インスタンスを取得して表示してみましょう。

サンプルファイルはSDKが入っているAWSSDKforPHPディレクトリと同じ階層に設置します。

$ ls
AWSSDKforPHP sample.php

サンプルソースは以下です。

まず require_once() でSDKを読み込みます(1)。これはどのサービスに対する処理を書く時も同じです。

次は、処理対象のリージョンを連想配列に格納しています(2)。SDKで処理を行う際は対象のリージョンをセットする必要があります。今回のサンプルでは全リージョンに対して処理を行うので、連想配列に格納しておきます。

次に、EC2へ処理を行うAmazonEC2クラスをインスタンス化します(3)。コンストラクタにて3-3で確認した認証情報をセットしています。第1引数が「アクセスキーID」、第2引数が「シークレットアクセスキー」となっています。

書籍のサンプルなどを見ると認証情報はSDK用の設定ファイルである「config.inc.php」に記載する例が多いのですが、個人的には認証情報は自分で管理したいのでコンストラクタで渡す方法がやりやすいです。

ここからAmazonEC2インスタンスに対して処理を行います。

まずset_region()で処理対象のリージョンを設定します(4)。そしてdescribe_instances()で対象リージョンのEC2インスタンス情報を取得して(5)、リージョン名とインスタンスIDをprintf()で出力しています。

この処理を各リージョン毎に行います。

3-5. 実行

ではサンプルソースを実行してみましょう。

下記結果から、us-westリージョンで1つ、ap-northeast(東京)リージョンで2つのEC2インスタンスが存在していることが分かります。

$ php sample.php
[us-west-1] i-xxxxxxxx
[ap-northeast-1] i-yyyyyyyy
[ap-northeast-1] i-zzzzzzzz

このようにAWS SDK for PHPを利用すると簡単な記述でAPIを実行して、AWSを操作することができます。

4. 参考書籍

Webに様々な情報があるとはいえ、これからはじめるなら、やはり書籍などまとまった情報をじっくり学びたいところです。

そこでAWSをこれからはじめるPHPerにおすすめな本をあげてみました。

G-CLOUD Magazine 2011

クラウド関連の情報が掲載されているムックです。AWSの特集があり、その中にAWS SDK for PHPの記事が掲載されています。

他にもAWSの記事も多く掲載されており、特にgumiさんの「Amazon EC2 API Tools」を活用したサーバ構築を自動化する記事が参考になりました。

Amazon Web Servicesガイドブック

AWSを活用するPHPerにはおすすめの定番本です。

この本ではAPIを利用してAWSを活用する実例が多数掲載されているのですが、それらのサンプルソースが全て「AWS SDK for PHP」を利用したものになっています。個人的にはタイトルを「AWS SDK for PHPガイドブック」にしても良いんじゃないかと思うくらいPHP満載のAWS本です。

内容も単に機能紹介を並べているのではなく、実際のWebサイトなどの構築を通じてAWSの各サービスを活用するアイデアが書かれています。

AWS SDK for PHP(aws.amazon.com)

書籍では無いですが、AWSサイトでは「AWS SDK for PHP」のドキュメントが公開されています。

導入方法にTips、そしてリファレンスが揃っており、SDKを活用していくには必須の内容となっています。

=> AWS SDK for PHP

AWSを触ってみましょう

いよいよクラウドの本格利用がはじまる今だからこそ、多種多様なクラウドサービスを個人で利用できるAWSを通じてクラウド利用の勘所を掴んでおくというのが大切だと思います。

さらに「AWS SDK for PHP」の存在により、PHPコードで手軽にそういったサービスをプログラムで操作することができます。

無料利用枠も提供されていますので、まだの人はぜひ一度AWSを使って、「プログラマブルデータセンター」と呼ばれるクラウド環境を体感してみてください。

AWSで気になること4つを聞いてきた – 第1回 JAWS Osaka勉強会

この記事の所要時間: 727

第1回 JAWS(Japan AWS User Group) Osaka勉強会に行ってきました。

大阪では貴重なクラウド系の勉強会、しかもAWSの方が来られる、さらにちょうどAWSを使える案件が出てきたタイミング(というか提案したのですが:D)ということで、参加してきました。

おそらく他の参加される方は「はじめまして」の人ばかりですし、せっかくの機会なので LT もやってきました。

ちなみに人見知りしたり、自己紹介が苦手だったりする人は発表してしまうのが良いですよ。発表の上手下手は関係無く、発表した人は印象に残りやすいです。数分でも自分の話を参加者全員が聞いて貰えるってなかなか無いですからね。
@see 勉強会を楽しむなら発表しよう!

AWSで聞きたいあれこれ

「AWSで聞きたいあれこれ」というタイトルでLTしてきました。

せっかくAWSエバンジェリスト、さらに識者の方達が集まる場なわけですから、日頃AWSを使っていてふと気になる疑問、「自分はこうしているんだけど、他の人はどうやっているのかなー」という質問を逆に聞いてしまおうと思い、通常の発表とは逆にみなさんに質問を投げかけるという内容にしました。

本当は山ほど聞きたいことがあったのですが、とりあえずという事で基本的な 4 つについて聞いてきました。

1. Region

質問

AWSアカウントを作って、さあ AWS Management Console で EC2 インスタンスを起動してみようと思った時にまず迷うのが region の選択です。(勉強会時点は)4 つの Region(US East / US West / EU West / Asia Pacific)があるのですが、日本向け Web システムを構築するならどの Region を選びますか?

参考までに、各regionにmicroインスタンスを立てて、国内からpingを打ってみました。RTTを見るとUS WestかAsia Pacificかなーと思うのですが、日本向けWebシステムを作るとしたらどのregionを選びますか?もしくは選んでますか?

会場からの回答

  • US West と Asia Pacific が半々くらい。US Eastもちらほら。EU Westはナシ。
  • Asia Pacificでも経路によっては、国内からでも80msくらい出る。
    => たしかにさくらVPSからだと70msくらい出ますね。
  • US Eastをあえて選ぶ理由は価格。
    => 速度を気にしなくて良い or 工夫できるなら、価格も大事な要素です。
  • RTTだけが重要なわけでは無い。
  • Asia Pacificを選んで困ったとこは特に無し。

感想

pingの結果を見ると、やっぱりUS Westを選ぶ人が多いように思っていたのですが、Asia Pacificの人も結構多かったです。ちょうどAsia Pacificのサーバを作っていたところだったので安心しました。

より近いregionができれば悩む必要の無くなるので、今後に期待したいですね。

2. AMI

質問

EC2インスタンスを起動するときに選ぶAMIですが、Amazon AMIやPublic AMIなどの公開されているAMIを利用しますか?それとも自分でイチからOSを入れて構築したAMIを使いますか?なお、前者の場合は起動したインスタンスをカスタムして別のAMIを生成することも含みます。

会場からの回答

  • 全員公開されているAMIを利用で、OSをイチから入れるという人はいませんでした。
  • 公開されているAMIを利用しつづけて困ったことは特に無い。
  • やはりAmazonとしては、Amazon Linuxがおすすめ?
    => 必ずしもそうではない。利用者の自由。
  • Amazon Linuxを利用すれば、AWS Premium Supportで有利?
    => 有利というわけではないが、Amazonで仕様を把握しているので回答は得られやすい。
  • 会場でも何名かの人が実際にAmazon Linuxを利用しました。

感想

ここもEC2を使う上で悩むポイントでした。

Googleで「EC2 AMI」で検索すると、AMIをOSイメージから作成する情報が多くひっかかり、逆に公開されているこのAMIを使うと良いといった情報があまり無かったので、実はOSイメージからAMIを作成してそれをラウンチするのが一般的なのかと思っていました。

個人的にはrightscaleのAMIを利用していて、それで困ったことは無いのですが、やはり同じような使い方をしている人が多いということで安心しました。また、Amazon Linux を本稼働で利用しているという意見も聞けたので今後は利用してみようと思います。

3. Root Device

質問

AMIを選ぶ時にも絡むのですが、Root Deviceの選択です。instance storeとEBSの2種類が選択でき、それぞれ特徴があります。どちらを利用していますか?利用しますか?

これはあくまでRoot Deviceだけの話で、instance storeがRoot Deviceでもデータ領域にEBSをマウントする方法は、前者になります。

会場からの回答

  • ほとんどの人がEBS。
  • サーバ用途にもよる。
  • 従来はinstance storeだったものをEBSへ移行している。
  • Root Deviceをinstance storeにしているのは、以前はRoot DeviceにEBSが利用選択出来なかったからでは。
  • EBSは速度的に不利という話があるが?
    => とくにそれで困ったという意見はありませんでした。

感想

EBSは数多くのメリット(インスタンス停止時にデータが消えない、スナップショット(バックアップ)が容易、AMIが簡単に作成できる、別サーバにattachできるなど)があるのでDevice Rootとして利用したいと思っていました。

速度的に不利という情報もあったので、実際のところどうなのかと思っていたのですが、とくに支障は感じないということだったので良かったです。

何か明確な理由が無いかぎりはEBSをRoot Deviceに選んで良さそうですね。

4. EBS Snapshot

質問

EBSの特徴でもあるスナップショットですが、簡単にボリューム全体のバックアップが取れるという優れものです。日々のバックアップとして利用しているのですが、実際のところ困ったこととかありませんか?

例えばスナップショットでバックアップを取っていたが、いざリストアしようとしたらデータが不完全で困った、など。

会場からの回答

  • 困ったという意見はナシ。
  • スナップショットはS3に保存される。S3の耐久性はイレブンナイン(99.999999999%)なので、まず大丈夫。
    => 自前でバックアップストレージ用意するよりはるかに安全ですね。。。
  • ただファイルシステムの整合性は担保されていないので、これは自分でフォローする。
    => 書き込みロックする、DBはダンプする、など。
    => 書き込みが頻繁で無いなら、世代数を多めに取るという考えもあり。
  • 念のため他のバックアップ方法と組み合わせている人は?
    => いませんでした。

感想

EBSのスナップショットは簡単にバックアップが取れるのでかなり便利なのですが、あまりに簡単過ぎて、根拠はないのですが若干不安があったりもしました。

そういった心配は不要でしたので、安心して利用できますね。

やってみて

逆質問という形式でやってみたのですが、多く方々から様々な意見を頂いて、とても勉強になりました。まだまだ聞きたい内容はあるので、また次回以降でやってみたいと思います。

回答頂いたみなさんありがとうございました!

雑感

こんなにAWSについて聞いたり話したりしたのは初めてでした:D

他の方の発表ももちろんですし、懇親会でも(ここでは書けない)色々なお話を聞くことができて楽しかったです。やはり「生の声」が聞けるのは勉強会の醍醐味ですね。進化が速いAWSだけに最新情報を共有できるこういった場は貴重です。

懇親会でJAWSの方々から「コアメンバーになる?」と声をかけて頂いたので、コアメンバーとしてお手伝いさせて頂くことになりました。具体的に何をやるのかはまだ分かっていませんが、コミュニティ活動に関わって行ければと思います。

会場提供頂いた富士ソフトさん、AWSのお二方、JAWSのみなさん、ありがとうございました!

日本国内のパブリッククラウド集

この記事の所要時間: 344

日本国内のパブリッククラウドをざくっと集めてみました。

クラウドがすっかり盛り上がってきました。新聞等ではいわゆるASP的なSaaSのクラウドが良く言われていますが、Webシステム屋としては IaaS / PaaS が気になります。

代表的なのは、Amazon EC2やGoogle App Engine、Azureの海外勢ですが、日本国内でもパブリッククラウドが立ち上がってきています。

2010/07現在で、どういったパブリッククラウドが国内にあるかをざっと並べてみました。

ここもあるよ!これ間違ってるよ!等々あれば教えて下さいm(_ _)m

対象

「クラウド」を謳っているサービスは多数あるのですが、ここでは以下に限定しました。

  • Webサイト(サービス)構築目的
  • IaaS もしくは PaaS
  • ユーザが任意にコントロールパネルでサーバ構成(リソース)を変更できる
  • 急激なアクセスに備えてオートスケール機構があれば尚良い

1. NIFTY Cloud

http://cloud.nifty.com/

  • NIFTY
  • IaaS
  • 法人のみ
  • 時間 / 月額課金
  • 勉強会やTwitter等でのPRが活発
  • ソーシャルアプリコンテスト等でサーバ提供を行っている
  • オートスケールは今後提供

2. ユニットホスティング

http://www.unit-hosting.com/

  • ディノ
  • IaaS
  • 個人 / 法人
  • 時間 / 月額課金
  • オートスケール機構は要問い合わせ

3. CUMO

http://cu-mo.jp/

  • 沖縄クロス・ヘッド
  • IaaS
  • 法人のみ
  • 月額課金
  • ロードバランサーは2010年秋提供予定

4. ホワイトクラウド(シェアードHaaSスタンダード)

http://tm.softbank.jp/business/white_cloud/haas_std/index.html

  • ソフトバンクテレコム
  • HaaS(IaaS)
  • 法人のみ
  • 月額課金
  • 提供サーバは1種類
  • Webからサーバ追加ができるかは不明

5. オンデマンド仮想システムサービス

http://oviss.jp.fujitsu.com/portal/ctrl/top

  • FUJITSU
  • IaaS
  • 個人 / 法人
  • 時間 / 月額課金
  • API提供アリ

番外. クラウドブースター

http://www.kagoya.jp/option/web/cloudbooster01.html

  • カゴヤ・ジャパン
  • ホスティング
  • 個人 / 法人
  • 時間課金
  • オートスケール可能なホスティング
  • クラウド程の自由度は無いが、実用はこれで十分かも

番外. NOAHプラットフォームサービス

http://www.idcf.jp/services/hosting/noah_p/platform.html

  • IDCフロンティア
  • IaaS
  • 法人のみ?
  • 月額課金
  • サーバ構成変更のリードタイムが?

番外. True CLOUD

http://www.truecloud.jp/

  • アイル(GMO)
  • IaaS
  • 個人 / 法人
  • 日 / 月額課金
  • 一日単位でのノード追加プランは2営業日前に申込が必要

番外. GrowServer2010-II

http://www.itcore.jp/growserver/

  • ITコア
  • ホスティング
  • 個人 / 法人
  • 月額課金
  • 回線トラフィック、ロードバランサー無料

番外. IIJ GIO

http://www.iij.ad.jp/GIO/

  • IIJ
  • ホスティング
  • 個人 / 法人
  • 日 / 月額課金
  • サーバ構成変更のリードタイムが?

まだ少ない。

EC2のように自由にリソースを変更できるクラウドを想像すると国内はまだまだ少ないですね。

正直、リストアップする前はもっとあると思っていたので、上手く見つけられていないのかもしれません。(教えて下さい!)

個人だとユニットホスティングしか選択肢が無いのが何とも厳しいですね。。。

いよいよEC2が国内に拠点を持つという話も出ているので、国内でも良いパブリッククラウドサービスが増えると良いですね。

Amazonからメール送信制限に関するEC2 Account Notificationが来た

この記事の所要時間: 437

とあるイベントで使うWebシステムでEC2を使ってたところ、Amazonからメール送信制限に関する通知が来たという話です。

このイベントでは、短時間で多くのリクエストを捌かないといけないので、あらかじめWebサーバを何台か立てて準備していました。さらに想定を超える負荷に備えて、増設用AMIも作成して、すぐに増設できる体制にしていました。もちろん増設のリハーサルもやりました。

そして、イベントが始まります。

アクセスがボチボチ来始めました。リソースにはまだまだ余裕があるので順調に捌いてくれています。とりあえず無難な立ち上がりだなと、ひと安心したところにメールが一通。

EC2 Account Notification

Dear EC2 Customer,
You recently reached a limit on the volume of email you were able to send out of SMTP port 25 on your instance:

Instance ID: i-xxxxxxxx
* IP Address: XXX.XXX.XXX.XXX
* Start date: 2010-NN-NN NN:NN +0000
……

うん?メールの送信制限?何これ?

たしかにメール送信は行っていますが、1hで数十通程度です。しかも一気に送るというよりバラバラと送信しています。この程度で制限がくるとは思わなかったのですが、イベント中に送信を止められるとシャレにならないので、すぐにメールに記載されたフォームからメール送信制限解除申請を送りました。

Request to Remove Email Sending Limitations – Amazon Web Services

本文の内容でググってみると同じようなメールが来た人は何人か見つかったのですが、解決したという内容は見あたりませんでした。中には実際に Port25 をblockされて、仕方なく外部のメールサーバに別ポートで接続してメールを送信している人もいました。

その時点では送信はできていたので、イベントが終わるまではとにかく持ってくれという心境でした。

何とか回避策を

制限解除申請をしたものの、ぼーと待っていても仕方が無いので取れる策をということであれこれやってみました。

まず、送られてきたメールにはインスタンスIDとIPが記載されていたので、別インスタンスとIPなら回避できるかもと思い、作成しておいたAMIから新しいインスタンスを起動しました。さらにElastic IPで別IPを発行しました。これはもともと高負荷時にスケールアウトすることを想定していたのですんなりと準備できました。

ここでふと、もしかするとアカウントを停止させられるかも、という考えが頭をよぎりました。もしそうなると何台増設していても意味がありません。

実際にそうなるかは分かりませんが、とにかく止められないので、新たなアカウントを発行することにしました。てきぱきと登録をこなして、スケールアウト用AMIの共有設定を行い、なんとかLB+Web+DBの構成を構築しました。

あらかじめDNSのTTLは短めにしておいたので、もしアカウントを停止された時はDNSを書き換えて別アカウントの構成にアクセスを向けます。

この間もサービスとしては問題無く稼働していました。

Amazonからメールが

あれこれやっているとAmazonからメールが来ました。

内容は「申請を受け付けた」「2営業日以内に回答するよ」といったもの。2営業日以内って!とか思いつつ、とにかく回避策をひたすら準備。

サーバログ(主にmaillog)と睨めっこしながらイベントが無事終わるのを待ちます。inboundもoutboundも変なエラーは無く順調に稼働しています。自分でもサイトにアクセスして試してみますが問題ありません。とにかく無事に終わってくれ。。。

乗り切った!

結局、blockされることなく無事にイベントは乗り切ることができました。やれやれ。

再びAmazonからメールが

無難にイベントが終わって、ひと息ついていた頃に再びAmazonからメールが来ました。

内容は「制限を解除した」とのこと。

本文には申請したインスタンス、IPに対する制限を解除しただけなく、アカウントに紐付く全てのインスタンス、IPに対する制限を解除した、と書かれていました。

対応は2営業日以内と書かれていたのですが、申請から数時間で対応してもらえたのは驚きでした。

イベントはこの日限りで翌日にはサーバを停止する予定だったのですが、今後の利用のためにElastic IPで割り振ったIPだけは残しておくことにします。

EC2からメールを送る際は念のため申請を

イベント中に来たAmazonからのNotificationには本当に焦りました。

それほど多くのメールを送ったわけではなく、どういった基準でこの通知が来るかは分かりません。イベント前のテストでは問題無かったので、閾値は低いものの一定時間中に一定数を外部に送信すると通知される仕組みなのかもしれません。

とにかく、ここぞの時にblockされるとシャレにならないので、EC2から数多くのメール配信を行うなら、あらかじめ制限解除申請をするなり、別環境を用意するなり準備をしておいた方が良いでしょうね。

ホーム > cloud > AWS

検索
フィード
メタ情報

Return to page top