第6回　ガジュアルなナレッジ共有でクラウドサービスを使い倒す～AWS（Amazon Web Services） Casual Talks

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される状態になってしまったのです。

最終的に、

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

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

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

他サービスとの比較を通してAWSが見えてきた

3番手の@naoya_itoさんこと伊藤直也さんは「MBaaSで巨人の肩に乗る」と題して、Parseの使用事例について紹介。後半ではAWSとMBaaSの比較考察も行いました。BaaSはクラウド時代のサーバ関連ミドルウェア的なサービスで、ユーザ管理・データ管理・プッシュなどの機能がひと通り揃っており、2017年には7700億円市場になるという予測もあります。MBaaSはそのモバイル版で、はてなブックマークをタイムライン形式で読むためのiOSアプリ「HBFav2」でも、数あるMBaaSの中からParseが使用されました。毎月100万APIコールまでなら無料で、抽象度がちょうどよく、PFQueryとの親和性も良好。スケーラビリティなども気にしないで使え、レイテンシもモバイルでは気にならない程度と言います。

ただし機能が便利すぎると、それに依存しすぎてしまうリスクもあります。伊藤さんは冒頭で星野さんが紹介したAmazon SNS Mobile Pushについても触れ、MBaaSほどの機能や柔軟さはないが、利用料が安いメリットを挙げました。もっとも、星野さんが指摘したとおり、プッシュ機能をSNS Mobile Pushで行うと、DeviceTokenの管理やユーザIDとのマッピングなど、細部を自社で作りこむ必要があるとも言います。伊藤さんは「AWSは部品で、MBaaSはサービス」だと説明し、依存リスクを避けるためにも、MBaaSはAWSの組み合わせて使用することを推奨していました。

最後に登壇した@shot6さんこと大谷晋平さんは、アマゾン社のエンジニアで会場提供者。そんな大谷さんは「AWS断捨離」と題して講演しました。断捨離すなわち不要なモノなどの数を減らし、身の周りをキレイにするだけでなく、ストレスから解放されてスッキリすること。たとえベストプラクティスとして紹介される活用事例でも、現場においては、さらにシンプルな構成にするのも一案だと指摘しました。その一方で、ただ不要な部分を削るだけでなく、さまざまなツールセットを活用して、自分だけのプラクティスを積み上げていく重要性について語りました。

大谷さんが重視するのは、AWSに過度に依存せず、AWSもまた1つの手段として能動的に使いこなしていく姿勢です。AWSはオンプレミスとは異なるため、軽快さを下げずに柔軟性を維持することが求められます。エンジニア自身がコスト意識を持ち、必要な機能は自分たちで実装する気概も必要でしょう。講演内では仮想マシンを簡単に立ち上げられるツール「Vagrant」と、オープンソースのAWSマネージメントコンソールで、オートスケールもバージョン管理できる「ASGARD」が紹介されました。そのうえでAWSサービスとの依存関係を考えて、どこまで踏み込むか考えて欲しいとまとめられました。

このほか@kenchanさんこと永和システムマネジメントの髙橋健一さんは、クラウドアプリケーション用のタスク調整と状態管理を行うサービス「Amazon Simple Workflow Service（SWF⁠）⁠」の活用事例について紹介。「⁠ワークフローの中で人手を入れるだけならFlow Frameworkを使用すれば良いが、途中でバッチ処理を挟む場合や、処理の順番を入れ替える場合は、自前で実装する必要がある」と指摘しました。また@hirose31さんこと、ひろせまさあきさんは「NATインスタンス冗長化の深淵な話」と題して講演。会場からは「パブリックIPが任意のVPCで使えるようになったため、NATインスタンスの意義も薄れつつある」といった声が聞かれました。

運営スタッフは1人という究極のミニマム仕様

さて、この勉強会を主催したのが、冒頭にも記した星野豊さんです。驚いたことに運営スタッフは星野さん以外にゼロ。つまり星野さんが自分の問題意識に基づいて企画・運営された勉強会というわけです。準備期間は約2ヵ月間。知り合いに声をかけたり、Web上で募集するなどして講演者が集められました。にもかかわらず、前述の通り募集開始15分で満員御礼になったのです。発表内容も星野さんの予想通り、普段なかなか一堂に会することのない濃いテーマが並び、参加者の満足度も高かったとのこと。勉強会として最高の立ち上がりとなりました。

前述の通り、告知されて15分で席が埋まっただけに、AWSの中上級者が中心かと思いきや、意外と「カジュアル」という名前に引かれて、初心者も多かったとのこと。いずれにせよアンテナ感度が高かった人ばかりだと言えそうです。なによりAWSの使いこなしかたについて、潜在的なニーズの高さが浮き彫りとなりました。これに対して星野さんは、発表内容も初心者向けから中上級者向けまで幅良くばらけて、良かったと振り返ります。

講演内で大谷さんから、AWSをさまざまなツールと組み合わせてカスタマイズしていく「ぼくのかんがえた最強のAWS」勉強会を開催したいという要望も出されました。こうした公式セミナーやハンズオンではとりあげにくい、ユニークなアイデアも、次回以降で考えていきたいとのことです。2014年1月～2月くらいに開催したいとのことで、今回参加できなかった人は要チェックでしょう。

またテーマに合わせて参加者の増減も見込まれることから、その都度で会場を探していくと話されました。一般的に勉強会の開催には「会場探し」「⁠コンテンツ（講演者への依頼⁠）⁠」⁠「⁠告知・宣伝」「⁠当日の運営」「⁠お金の管理」など課題となりますが、中でも一番大きいのが会場探し。一方で今回、多くの参加希望者が出たことから「Ustreamなども機材がそろえば考えたいですが、きわどい話ができなくなる恐れも……」と語ります。実際オフラインだからこそ共有できるナレッジもあります。ぜひ適切な会場が借りられることを期待してやみません。

本勉強会で改めて感じたのは「熱意があれば1人でも勉強会は開催できる」こと。そして「自分の一番関心があることにテーマを絞ったほうが、かえって多くの人にリーチできる」ということです。星野さんも「これからも発表者が興味のある話題を好きに話してもらえる会にしたいですね。きわどい話も出てくるといいなあと個人的には思っています」とのこと。まさに「自分が楽しいと思えないことが、他人に喜ばれるはずがない」ということなのでしょう。究極のオレ様マーケティングこそが正解といえそうです。

最後に星野さんから、勉強会やコミュニティ活動に臆しているエンジニアがいたら、ぜひ自分の興味のあるテーマから足を運んだり、ライトニングトークから発表してみてはと勧められました。「⁠最初からコミュニティを立ち上げようとせずに、まずは興味あるテーマで勉強会を開いてみると、案外気楽にできるのではないでしょうか。無理にコミュニティにする必要もないと思います。AWS Casual Talkもコミュニティではなく、勉強会ですので」（⁠星野さん⁠）⁠。スタートしたばかりの本勉強会が、どのように成長していくか楽しみです。