Twitterでまとめてたら140文字に入り切らなくなったのでブログにまとめておきます。
さぁて、どれ行こうか？ｗ
twitter、Facebook はもちろんのこと mixi や Gree へリンクを共有する仕組みを実現する機能を実装していたのですがちょいとはまりました。開発環境で動作確認を行っていると外部からのアクセス制限をかけている関係で各種ソーシャルサービスで正常に動作しません。
リンク共有のアクションを行うとソーシャルサイト側からコンテンツのチェックされ Open Graph Protocol のメタタグが読まれてリンク情報が表示されるという流れなので、Basic認証やIPアドレスなどのアクセス制限がされていると正常に動作しないわけですね。
対処方法ですが、すべてアクセス許可するのがOKなら問題ないわけですが、一般向けには公開したくないのであれば各ソーシャルサイトの共有機能からのアクセスだけ許可すれば良いです。
調べてみると各サービスでリンク共有すると以下のようなUserAgentでアクセスされることがわかりました。これでチェックすれば行けそうですね。
cloudpack (旧AWS+)を始めてから、幾度となく日本にデータセンターがあるサービス事業社と比較され心理的不安や法律的不安について聞かされ、残念な思いをしてきた… 積もり積もった思いはとりあえずおいておいて。
ついにAWS東京リージョンが登場しました。「東京」とついてるからには地理的に「東京」に位置しているわけでネットワーク的には近いはず。とりあえずシンガポールのときと同様に簡単にレイテンシを計測してみます。
[ec2-user@tokyo-region ~]$ ping -c 10 ae-5.r21.tokyjp01.jp.bb.gin.ntt.net PING ae-5.r21.tokyjp01.jp.bb.gin.ntt.net (129.250.11.53) 56(84) bytes of data. 64 bytes from ae-5.r21.tokyjp01.jp.bb.gin.ntt.net (129.250.11.53): icmp_seq=1 ttl=57 time=3.77 ms 64 bytes from ae-5.r21.tokyjp01.jp.bb.gin.ntt.net (129.250.11.53): icmp_seq=2 ttl=57 time=3.80 ms 64 bytes from ae-5.r21.tokyjp01.jp.bb.gin.ntt.net (129.250.11.53): icmp_seq=3 ttl=57 time=3.71 ms 64 bytes from ae-5.r21.tokyjp01.jp.bb.gin.ntt.net (129.250.11.53): icmp_seq=4 ttl=57 time=3.65 ms 64 bytes from ae-5.r21.tokyjp01.jp.bb.gin.ntt.net (129.250.11.53): icmp_seq=5 ttl=57 time=3.69 ms 64 bytes from ae-5.r21.tokyjp01.jp.bb.gin.ntt.net (129.250.11.53): icmp_seq=6 ttl=57 time=3.70 ms 64 bytes from ae-5.r21.tokyjp01.jp.bb.gin.ntt.net (129.250.11.53): icmp_seq=7 ttl=57 time=3.78 ms 64 bytes from ae-5.r21.tokyjp01.jp.bb.gin.ntt.net (129.250.11.53): icmp_seq=8 ttl=57 time=3.81 ms 64 bytes from ae-5.r21.tokyjp01.jp.bb.gin.ntt.net (129.250.11.53): icmp_seq=9 ttl=57 time=3.78 ms 64 bytes from ae-5.r21.tokyjp01.jp.bb.gin.ntt.net (129.250.11.53): icmp_seq=10 ttl=57 time=3.74 ms --- ae-5.r21.tokyjp01.jp.bb.gin.ntt.net ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9015ms rtt min/avg/max/mdev = 3.654/3.748/3.813/0.063 ms
その他価格などは別で報告します。
AWS のロードバランサー ELB を利用して複数のウェブサーバーをぶら下げる構成を準備している際に、公開前なのでBasic認証をそれぞれのウェブサーバーで設定してまうと外部から一切アクセスできなくなってします。この現象、自分ではまって解決したのにしばらくぶりに作業すると忘れていて、またはまる… そんな経験をしたのでメモしてく。
原因: ELBのヘルスチェック機能からも /healthcheck.txt へ正常にアクセスできなくなるため異常発生扱いになりウェブサーバーが切り離されるため
解決法: Apache 設定ファイルのどこかにこれを書いておく。（当然 /healthcheck.txt ファイルは事前においておくこと）
<Files healthcheck.txt> Satisfy Any Allow from all </Files>
ところで最近はサービス説明ページが日本語されていて便利になりましたね。そのうち Management Console も日本語されちゃうのでしょうか。
AWSのFirewall機能といえば Security Group ですが、意外にシンプルな機能でプロトコル、アクセス元、ポートのレンジを指定したセットをEC2起動時に指定してアクセス制御を行うしかけになってます。このままでも運用しても良いのですが、AWSブログで3tier構成にする場合の解説があったので紹介します。
suz-lab でも解説があったとおり、セキュリティグループの設定値で Source としてセキュリティグループを指定することができます。これは指定したセキュリティグループからの特定のポートへのアクセスを許可する方法です。
これを利用することで、いわゆる Internet – DMZ – LAN 的な 3tier を作ることができます。AWSブログでは WebSG、AppSG、DBSG というセキュリティグループを作成して、WebSG → AppSG、AppSG → DBSG の接続許可をしてます。API（コマンド）では以下のとおり。
photo by chotda（まとまりは無いのですが、ビビっと来たのでメモしておきます）
先日クラウドEXPOに行ってきたが自分がイメージしていた「クラウド」とはかけ離れたいろんな会社やサービスがいて、一方で「帳票！」という言葉も目にして、何だかなぁと思った。彼らの提供するプロダクトやサービスは、自分が考える幸せな環境と全く違うのです。
最近 AWS+ を始めたこともありクラウド導入の話が多くある。ほとんどの場合まずはじめにどういう結果を重視するのか確認しているのですが、最近の案件でよく話す「クラウドを導入すべき大きな理由」は2つあります。完全に従量制になるので需要とぴったり合致したインフラ利用（増減）が可能になり実現する経済性か、もしくはインフラが完全に仮想化・サービス化されていることで手に入れられるスケールアップ/アウト可能な環境なのか。意識的に分けて説明しないと相手のイメージもモヤモヤしたままになってしまうので注意が必要。
ところが最近よくきくホスティングサービス事業者による「クラウド」サービスは、単純にVPSや今までのレンタルサーバー的なサービスの延長上にあるだけで、完全従量課金制のものは皆無だし自由に拡張しようにも手続きがある、リアルタイムに拡張可能なものはプライベートクラウドを買わせられるはめになるものばかり。
はて、なぜ「何だかなぁ」と思うのか、ここでやっと気づきました。
昨年秋に公式に発表されて、今年上期に利用開始予定となっていたシンガポールのデータセンターがなんと本日サービスインしました。
発表によれば、以下のサービスが利用可能になったそうです。ちなみにアメリカ西海岸のRDSは無かったのですが、先にシンガポールで対応してます。
Amazon Web Services で複数のEC2インスタンスへロードバランスさせたいときに使用する Elastic Load Balacing に Sticky Session がサポートされました。
New Elastic Load Balancing Feature: Sticky Sessions
ロードバランスされた環境では HTTP リクエストごとに特定のアルゴリズムに従って振り分けされて負荷分散・冗長化構成としての効果を出すわけですが、ユーザー毎（セッション毎）の情報をウェブアプリケーション内で持つ必要のある構成の場合、どのインスタンスにリクエストが来ても同じ状態にしなければならないため memcached を導入したりして自前でセッションデータの共有をしておく必要がありました。
今回のアップデートで一旦始まったセッションを引き続き同じインスタンス（サーバー）へ転送することが設定で可能に。Cookie を使用して実装されているため、事前の設定以外でウェブアプリケーション側で気にする必要はなくシームレスに導入できるのがよいですね。（普通のロードバランサーと同じですが）
本番投入に当たっては、いずれかのサーバーが死んだ場合どうなるかとか、アプリから能動的にセッションを切れるのかなど、もう少し調べないといけないですがウェブアプリケーション本番環境の構成として必要なものがどんどんサービス化されるのはとても助かります。
少し探してもなかなかドンぴしゃな情報が出てこなかったので記録のためにまとめておきます。（最後の最後、結局自分の書いた記事にたどりついてヒントを得たりして）
運用中のサイトのメンテナンスなのに一時的にサイト全体のアクセスを禁止して、停止中のお知らせを出すようにしたい、かつメンテナンス中作業者によるアクセス確認のため特定IPからはアクセスを許可する設定は以下のようになります。
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^192\.168\.0
RewriteRule ^.*$ /maintenance.html [L]
上の例だと、192.168.0.* からのアクセス以外は /maintenance.html の内容を表示するというものです。他のIPやネットワークアドレスを追加したければ RewriteCond を追加すればよいですね。
RewriteCond, RewriteRule はだいたいどのコンテキストでもかけるので、自分の場合は利用する VirtualHost 内に追記してます。
以上。こんなもんかな？
クラウドコントロールサービスの大手RightScaleが管理している仮想サーバーの数がもうすぐ100万台になるそうです。100万台超えるのは時間の問題ですが、4月に行われるイベント時点で何台になっているかを当てるコンテスト（クイズ）を行ってます。
近い順から3名に iPad をプレゼントするみたいなのでぜひ挑戦してみてください。（最近 iPad プレゼント系のコンテスト多いですね）
ちなみに今までの台数推移は以下のとおり。