先日サーバーメンテナンス時にちょっとした不具合が発生しEC2の起動ができなくなりました。一瞬気が遠くなったのですが(笑)、原因がわかったので無理やり対処した記録です。
他のメンバーからの報告で、再起動しても、AMIから復旧しようとしても起動しない、というか起動しても接続できないとのことだったので、Management Consoleから System Log を確認すると以下のメッセージが。
*** ファイルシステム検査中にエラー *** シェルに移行します、システムは再起動します。 *** シェルから抜ける時。 Give root password for maintenance (or type Control-D to continue):
エラー発生しているのはrootボリュームではなくデータ専用ボリュームだったのですが、入力待ち状態のため正常起動せず /etc/fstab すら書き換えられない状態だったのです。
ということで、手順をまとめるとこんな感じ。
aiCacheのユニークな機能をまとめます。
・HTTPSターミネーション
・モバイル端末対応（リダイレクト、リクエスト書き換え・TTL変更など）
・GSLB対応（Dyn.com連携）
・レスポンスによるキャッシュ削除
・セッション毎のキャッシュ管理（ログイン中もキャッシュ管理可能）
・POSTリクエストのキャッシング
・指定URLのプリフェッチ
特に「レスポンスによるキャッシュ削除」と「セッション毎のキャッシュ管理」は良いですね。
先日に引き続きaiCacheネタ。
今回はセットアップ編。
aiCacheは有償の製品です。価格モデルとしては、パッケージ型ライセンス購入もしくはクラウド（従量課金）型の2種類から選択できるようになってます。
パッケージ型の場合の費用はこちらにあるので詳細は割愛しますが、HTTPSとモバイル向け機能が含まれるEnterprise版は$18,995、QA目的でも定価は$9,995と簡単に導入できる金額ではありません。
クラウド型の課金モデルを選ぶと、Amazon PaymentでaiCacheのサブスクリプション契約（$0.71/月）をすればその後は利用料を上乗せされた形での課金方式になり、もちろん時間課金・データ量課金となるため安価に始めることが可能になります。
ということでセットアップしてみましょう。
手順は以下のような形になります。
（0. AWSアカウント作成）←必要があれば
1. aiCache利用申し込み（サブスクリプション契約）
2. aiCache初期設定ファイル作成および設置
3. aiCache AMIによりインスタンス起動
本日8月4日にAmazon VPCのベータが取れてサービス・機能の拡充がされました。Twitter界隈ではさまざまな情報が流れていて、ここで改めて書くのもアレなので、逆張りして、制限についてまとめておきます。
VPCのページを眺めると Other Notes に制限がまとめられてました。
てきとー日本語訳。
原文はこれです。
Other Notes
Please note the following about Amazon VPC right now:
– AWS Elastic Beanstalk, Elastic Load Balancing, and Amazon Relational Database Service (Amazon RDS) are not available for use in a VPC at this time.
– Amazon EC2 Spot Instances, Cluster Instances, and Micro Instances are not available in a VPC at this time.
– Amazon DevPay paid AMIs are not supported in Amazon VPC.
– You can have up to five (5) Amazon VPCs per AWS account per Region.*
– You can create up to twenty (20) subnets per Amazon VPC.*
– You can have up to five (5) Amazon VPC Elastic IP Addresses per AWS account per Region.*
– You can have up to ten (10) Hardware VPN Connections per Amazon VPC.*
先日に引き続きaiCacheネタ。
まだ製品はさわれてませんが、スタディのため資料を読みあさってます。ビデオも多く準備されていて勉強できます。多くのビデオがCEOの顔ドアップでびっくりしますが平易な英語で解説してるので理解しやすいです。
■aiCache Overview
■aiCache in the Cloud 250K
■aiCache site monitor on AWS with Giant Digital
その他のビデオはこちら。
ウェブサイト以外で発表資料がないか調べていたら Slideshare に一点ありました。
本日はAWSのパートナー商品を紹介してみます。
今回は、クラウド環境を利用してダイナミックアプリケーションにも対応するキャッシュ製品 aiCache です。aiCacheはAWSおよびRackspaceに対応しており、AWSのSolution Providerのひとつです。
Solution Providerでの紹介を読むとアプリケーションサーバーのフロントにaiCacheを入れることで、以下のような効果を得ることができるとあります。
・コスト削減
・アプリケーションをスケール
・システムの安定稼働
（これだけだとすごく普通…）
EC2向けにはAMIが準備されていて、かつ利用料はAWSの従量課金に上乗せする方になってます。
さて本日も小ネタを。
最近General AvailabilityステイタスになってBetaが取れたRoute53ですが、なんとSLA100%だそうです。
Service Commitment
AWS will use commercially reasonable efforts to make Amazon Route 53 100% Available (defined below). In the event Amazon Route 53 does not meet the foregoing commitment, you will be eligible to receive a Service Credit as described below.
Amazon Route 53 SLA より
絶対落ちないことを保証しているのか？と勘違いしそうですが、1秒落ちてもAWS側に責任があると定義しているだけですね。当然サービス継続の努力は怠らないけれども、一定時間落ちてもよい契約ならば100%ではなく99.95%とかそういう数字になるだけです。EC2なんかはそうですね。
ではサービスが一定時間落ちたらどうなるかですが、長さによってサービスクレジット（料金）をリファンドすることになります。時間とクレジットのマトリクスは以下のとおり。
1 day Service Credit は “your average daily Route 53 query charges” とあるので利用（請求）期間中の1日平均クエリー料金が適用されます。ボリュームによってかわるけど、要するにRoute53 1日分の料金にあたるわけです。
SLAというキーワードで100%なんて数字聞いたことなかったので驚きましたが、ちょろっと調べてみたら契約モデルとしてはとてもフェアなものでした。
AWSのニュースレター（メール）を見ていたら気になるものがあった。
Customer Feedback on the AWS Management Console
We’ve launched a new Customer Feedback feature for the AWS Management Console. Using the Feedback link at the bottom of the Console screen, you can now easily provide Console feedback directly to the AWS team. Alternatively, you can tell us what you think about the Console in this short survey. Please take a moment to share your opinions as customer feedback directs our investments and improves the experience we deliver to you.
Management Console 画面の下にフィードバック用のリンクがついたということです。以前からもフォームはどこかにあったと思いますが、見つけるのに一苦労してた記憶が。
今回の変更で Console 使用中、つまりログイン済みでアカウントIDもわかる状態で、使用中に発生した不具合を手間無くすぐに報告できるようになったわけですね。小さな変更だけど、ちょっと便利に。ユーザーの方を向いてますよというメッセージにも見えるのはイイですね。
Feedbackをクリックするとフォームが出現。
ちなみにAWSでは各サービスでアンケートやったり、常時こういうアンケートをやって新サービス・新機能実現のプライオリティを決めているみたいですよ。
そういや #AWS77 はちゃんと取り込まれるのかしら？
AWS日本語ブログ、SEOが全然効いていない気がする。
Hirotomo Oi
hiroohi
そうなんですよね。分かっているなら専用カスタム検索作った方がいいかもしれませんね。 RT @hiroohi: AWS日本語ブログ、SEOが全然効いていない気がする。
Kazutaka Goto ☁
kaz_goto
ということでつくってみました。個人的にはよく使うかも。
検索時に「〇〇 site:aws.amazon.com/aws_japan/」とかよく使ってたので。
EC2では内部から Instance Metadata というインスタンスの情報を取得可能になっていて、簡単なURLリクエストでデータにアクセスできます。
参考: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/index.html?AESDG-chapter-instancedata.html
Twitterを眺めていたらふと @maru_tak さんが「http://169.254.169.254/latest/meta-data/ が覚えにくいので…」とつぶやいていて、確かに自分でも「便利なURLだったけどいつもURL忘れていて検索してたな」と思い出したのでした。
で、あれば、覚えやすくするために… 短縮URL！ということで bit.ly を使って短縮してみました。メタデータ名は壊さず、できるだけ規則的になるよう以下のように短縮してみました。