今年は本当に恵まれた年だった。本来3月の大地震、そして身内に不幸が続いたりして、本来ならばネガティブな流れだったはず。
ところが驚くほど多くの出会いに恵まれて、公私問わず喜怒哀楽を出し切れる仲間に出会えたことでこの一年がんばれた気がする。公私を分けずにいる状態、それが逆に心地良くて、おかげですべてが充足感のある一年だった気がする。
特に地震の際は、仲間とともにAWSの協力のもとボランティアで各種ウェブサイトの復興を手伝ったわけだが、これが思いの外楽しかった。緊急時の対応なのだから真剣にやっているのはもちろんだが、本来の仕事そっちのけでこういう判断をして取り組む、そうした思いに全くブレがなく一致してたことや、それぞれが持つ能力を出し切りつつ「あ・うん」の呼吸で役割分担する。こうした経験を通じて、より信頼感が高まったのだと思う。
さてさてハードだった今年をカレンダーを見て振り返ってみようと思う。
—
オランダの認証局DigiNotarが不正にシステム進入を受け、さらには不正なSSL証明書が発行されていたことがわかり、業界内が騒然としていますが、認証局情報は身近にも存在するので注意が必要です。
ブラウザなどもベンダーによる対処が進んでますが、AWSにおいても一部影響があるため対応が必要になります。
その一つが認証局証明書 cacert.pem のアップデート。全範囲での調査が終わっているか定かではないですが、とりあえず AWS SDK for PHP 内にある cacert.pem はアップデートが必要とのこと。
■Announcement: [UPDATED] Potential SSL security vulnerability. Please read.
9月8日時点で 1.4.2.1 がリリースされているので古いバージョンを利用中の方はアップデートしてくださいませ。
なお、どうしても古いバージョンを利用したい方は cacert.pem ファイルを手動で更新しろとあります。該当する方は対応をお早めに。
If you are still using an older version of the AWS SDK for PHP for one reason or another (versions 1.3.2 through 1.4.1), we strongly recommend that you update the cacert.pem file located at
/lib/requestcore/cacert.pem with the latest version from http://curl.haxx.se/ca/cacert.pem.
今回はMySQLの超小ネタ。
バイナリログ出力を設定していると日々変更ログがたまっていくわけですが、一定期間分だけ保存するよう設定しないと無尽蔵に増えていってしまいます。その制御をするパラメータが expire_logs_days です。
何も指定してないとデフォルト値 0 になっていて永久に保存になってますが、整数値を指定すればその日数の分だけ保管され、それ以上過去のものは自動的に削除されるようになります。
例: expire_logs_days が 7 だと7日間分のバイナリログだけ保存される
expire_logs_days はマニュアルを見ると「Dynamic Variable: Yes」とあるのでオンライン（起動中）で変更可能です。やってみましょう。
先日サーバーメンテナンス時にちょっとした不具合が発生し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%なんて数字聞いたことなかったので驚きましたが、ちょろっと調べてみたら契約モデルとしてはとてもフェアなものでした。