IT勉強会に突撃レポートし，開始のきっかけや，運営ノウハウなどについてお聞きしていく本連載。第6回目はAWS（Amazon Web Services）の使用事例やノウハウについて，現場のエンジニアがガチで語る勉強会「AWS Casual Talks」をご紹介します。2013年11月1日（金）に開催された記念すべき第1回目の勉強会は，50名の参加枠がわずか15分ほどで埋まり，最終登録者数は210名にまで上ったという盛況ぶり。当日キャンセルもほとんどなく，会場のアマゾン データ サービス ジャパン（以下アマゾン社）会議室では，終始ガジュアル（ガチ＋カジュアル）なトークが繰り広げられました。

カジュアル＝初心者ではない！？

AWSは米アマゾン社が提供するクラウドコンピューティングのサービスです。サービス事業者は固定サーバを立てるのと同じ感覚で仮想サーバを使用でき，エンタープライズ向けの大型アプリケーションからモバイルアプリに至るまで，さまざまな物をクラウド化できます。トラフィックの急増にもスケーラブルに対応でき，設定もWebブラウザ上で完結。ツールやサービスのエコシステムも存在し，数多くの業界や企業で導入が進んでいます。セミナーやハンズオンも頻繁に開催されており，ちょっと検索するだけでも，さまざまな情報を入手することが可能です。

しかし，これらの情報の多くは教科書的で，初心者にもわかりやすく懇切丁寧に説明してくれるのは良いのですが，今一歩深みが足りないのも事実。実際に使ってみて初めてわかる感想や疑問点，アイディア，テクニックなど，痒いところまで手が届く情報は，なかなか得る機会がありません。そうした情報を共有できる場所がないなら，自分で作ってしまえば良い。「⁠AWS Casual Talks」も主催者の@con_mameさんこと星野豊さんの，そんな熱い思いからスタートしました。

星野さんは料理レシピサイトでおなじみのクックパッドで，インフラ制作に携わるエンジニア。AWSというテーマ設定もあり，第1回目はアマゾン社の大谷晋平さんの協力を得て，同社会議室で開催されました。共同運営ではなく，あくまでユーザ主導の勉強会。星野さん，大谷さん共に会社とは関係なく，あくまで個人的な活動とのことです。

冒頭挨拶で「カジュアルという名称からか，AWS初心者の方も参加されていますが，カジュアルに初心者という意味はありません！」と切り出した星野さん。他にも「Casual Talks」と冠の付いた勉強会はあるが，いずれも技術が好きな人がカジュアルに話をするので，結果的にガチな話ばかりになると続けました。そんな第1回目の共通テーマは，星野さん自身が関心があったという「誰にも聞けないAWSのこと⁠」⁠。30分程度の講演が4本と5分程度のライトニングトークが2本行われ，参加者も真剣に聞き入っていました。

なお，当日の発表資料などは星野さんのブログにリンクが整理されています。

本勉強会でしか聞けないガチトークがずらり

はじめに星野さんは「気軽なSNS Mobile Pushのはなし」として，SNS Mobile Pushを使用するうえでのテクニックや注意点について講演しました。スマートフォンなどの端末にサーバから通知を送るプッシュ機能には，AppleやGoogleをはじめ，各社からさまざまなサービスが提供されていますが，仕様が統一されていません。そこでプラットフォームごとのAPIを抽象化した中間プロバイダが注目されており，Amazon SNS Mobile Pushもその1つです。星野さん曰く「100万プッシュあたり1ドルと格安で，安定して動作し，AWS内で完結する」とメリットを語ります。

一方で使用時には少々注意が必要です。中でもアクセス情報が漏れた場合などに備えて，Token Vending Machineを併用するのがお勧めだと語られました。これにより万が一の事態でも，Keyなどが1時間程度で使用できなくなります。またSNS Mobile Pushに登録ずみのDeviceTokenを改めて登録する場合は，現在のところCustomer User Dataまで同一にする必要があると注意が促されました。他にも全デバイス向けに一斉に通知したり，メタデータに応じたプッシュ通知を行ったりと，何か特別なことをする場合は自前で管理する必要が出てきます。そのため事前に，仕様をよく把握しておく必要があると整理しました。

二番手の@Yuryuさんこと岩尾はるかさんは，「⁠カジュアルにVPC作った結果がこれだよ」と題して，AWSでAmazon Virtual Private Cloud（VPC）を使う場合のハマリポイントについて，実体験をシェアしました。VPCとはクラウド内に自分のプライベートクラウドを所有できるサービスのこと。これによってAWSユーザは，自社サーバルームの延長のように自由にアクセスできる一方で，インターネットから隔絶されたネットワーク空間を無料で使用できます。VPN経由でオンプレミス（自社運用型）のサービス環境とも接続可能。しかし，マニュアルには掲載されていない落とし穴があると言います。

まずはじめに，VPCとサブネットを同じサイズにしてしまったため，追加や変更ができなくなりました。一度設定するとサイズの変更ができないため，開発途中で泣く泣く削除して作り直したそうです。次にサブネットをパブリックとプライベートに分けることなく，パブリックサブネット内にプライベートIPしか持たないインスタンスと，NATインスタンスの両方を設置してしまいました。そのため，同じサブネット内でルーティングが異なる結果をまねき，起動後にデフォルトゲートウェイを変更しなければ，外部との通信ができなくなりました。しかもデフォルトゲートウェイがNATを向いているため，この状態でサブネットを追加したら，プライベート通信がNATされる状態になってしまったのです。

最終的に，

1. パブリックサブネットを新規追加し，NATインスタンスを移動
2. デフォルトゲートウェイをVPCルータに変更し，既存サブネットのデフォルトゲートウェイをNATインスタンスに設定
3. ELBも新規作成

――という手順を経て，トラブルを解決できました。

最後に岩尾さんは「サブネットを大きくし過ぎない」「⁠プライベートとパブリックでサブネットを分ける」「⁠ELBはパブリックサブネットにアタッチする」とTIPSをまとめました。ちなみに，パブリックサブネットとプライベートサブネットを分離しなかったために起きたトラブル事例については，ライトニングトークで@hirose31さんこと，ひろせまさあきさんからも語られました。意外と気づかないハマリポイントのようです。