この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
本日開催されました、「【リベンジ】JAWS-UG 千葉支部 Vol.3 -AWSスタートアップあるある」に参加してきました！本イベントは元々2014年2月15日に開催される予定でしたが、豪雪により延期となったものです。
会場は新浦安駅のすぐそばにある、浦安市民プラザWave101の多目的小ホールです。ステージ上に大きなスクリーンがあり、演台がライトアップされるという、素晴らしい会場でした。
この会場でお話しします。このエンタープライズ感… #jawsug #chibadan http://t.co/4IvrPtRn9Q
— hiroshix (@hiroshix) April 5, 2014
なお今回の会場はeXcaleチーム様にご出費頂いたとのことで、一参加者として感謝致します。ありがとうございます！
レポート
今回のイベントに関連したtweetはTogetterにまとめましたのでそちらも併せてお読み下さい。また誰でも編集可能にしてありますので、ご参加されていた方で追記等がある方はご自由に編集下さい。
講演者の方のスライドについては、公開されたものから順次追加させて頂きます。
「スタートアップのためのAWSピーク対策入門」 by アマゾン データ サービス ジャパン 株式会社 高山 博史さん
高山さんのお話としては、AWSとスタートアップの相性の良さと、そしてAWSにおけるピーク対策についてお話頂きました。
Amazonが何故クラウドサービスを始めたのかという事について、Amazon.com自体のシステム上の問題点、例えばスケール出来ない構成や高額なハードウェア、インフラの拡張スピードの遅さに引きずられてサービスリリースが遅延してしまう問題などを解消するために試行錯誤したノウハウをサービスとして提供したものが、Amazon Web Servicesであるとのこと。
スタートアップだったAmazon.comが通った苦労をサービスとして提供しているからこそ、今あるいはこれからスタートアップする企業にとって痒いところに手が届くサービスになっているとのことでした。もちろんスタートアップだけで無く、攻めの姿勢を持ったエンタープライズ企業にも選択されているのは、昨今の事例からも分かりますね。
ピーク対策についてのポイントもたくさんお話頂きました。ピークというのはテレビなどのメディアの場合ある程度予測がつきますが、所謂ニュースサイトなどからのアクセス増加は予測が出来ず突然発生する場合が多いかと思います。こうった急激なアクセス増があった後に改修するのは大変なので、早めに早めに対策しておいたほうがいいとのことでした。例えば初期導入時にシングルインスタンスで構成してしまうと後から冗長化構成とするのは大変ですが、最初から冗長構成となったシステムで後から冗長機器を追加するのは簡単なので、最初から冗長構成を考慮して設計しておいたほうがいいことや、ELBの負荷に比例したスケールは徐々に大きくなるため負荷のバーストには間に合わない場合があることから、予測可能なピークの場合は事前にAWSサポートからプレウォーミング(暖機運転)の申請をした方が良いなど、ピーク対策のノウハウがたくさん詰まったお話でした。
また僕が重要なお話だと思ったのは、アンチパターンとしてご紹介されていたもので、テレビなどから発生するトラフィックのバーストを甘く見積もっていて中途半端なスケールアウトしかせず、結果的にサービス障害が発生して機会損失が発生してしまうことがあるというもの。最終的に10%程度しか使われなかったとしても損失は少ないが、サービス提供出来ないことの損失はとても大きいので、最初のスケールアウトは思い切り良くやって、その経験を2回目以降の調整に使った方が良いとのことでした。
最後に質疑応答としてオートスケールの使用について質問があがりましたが、オートスケールは閾値の調整などが面倒な場合が多く、手動スケールを使っている場合のほうが多いのでは無いかとのことでした。自動でも手動でも、スケールが可能な設計にしておくということが重要なのでしょうね。
「eXcaleによるAWSの利用方法」 by TIS 株式会社 西谷 圭介さん
西山さんからeXcaleのサービス構成についてお話頂きました。詳しくは上述のスライドをご参照下さい。細かい構成まで記載されていてとても参考になります。コンテナベースでのPaaSサービスとのことで、Heroku的なサービスなんですね。
面白かったポイントは幾つもあるのですが、一つは本番環境のミニマム構成にしたステージング環境を日次で起動→停止を繰り返していると、Spikyアカウントと見なされて制限がかかったそうです。このSpikyという制限は知りませんでした。
またAutoScallingは使わず、独自の計算スクリプトを使用してインスタンスの立ち上げやTerminateを行われているとのことで、eXcaleさんのようなEC2の上にXLCコンテナでサービス提供しているような場合だと、単純なオートススケール設定だけだと対応仕切れないんだろうと感じました。また、現在システムを第二世代化しているとのことですが、早速VPC Peeringを使っているそうです。
かなり内部的なノウハウまで共有して頂けた、素晴らしいセッションでした。
「AWSの困った話とバッドノウハウ」 by 株式会社 アールラーニング 小田島 一樹さん
初っ端から「話せません」からスタートしました。諸事情で色々と話せない部分が多くなり、スライド枚数を大幅に削られたそうです。お疲れ様でした...
そこで、公開出来る範囲でのバッドノウハウなお話をして頂きました。以前のcloud-initでルートファイルシステムのリサイズが効かないこと(Amazon Linux 2014.03でCloudInitが0.7.2になったことで解消されました) であったり、SESでの携帯キャリアへのメール送信の制約で困ることが多くてSnedGridを検討されている事など。以降のお話でもSendGridの名前は良く出されていました。メール配送を行うスタートアップではSendGridはよく選択されているとのことで、僕も学んでおきたいところだなぁと感じました。
「スタートアップの成長とAWSの活用」 by freee 株式会社 横路 隆さん
最近あちこちでお名前を拝見することが多い、freeeの横路さんのお話。freeeのサービスについては、またその中でAWSをどのように使われているかについてお話頂きました。
当初freeeはさくらVPSとHerokuの組み合せでサービスを構築されたそうですが、結果的に全てAWSに置き換えられたそうです。AWSを使われるメリットとしては、スモールスタート出来ること、フルマネージドサービスが増え続けていること、開発者もインフラ担当者もシームレスに使うことが出来ること、などをお話されていました。
すみません、このセッションは興味津々すぎてメモをあんまり取れなかったです...スタートアップとして始めたサービスがAWSのリソースをどのように使って拡張していくのか、という経緯が聞けて、とても面白かったです。後日のスライド公開を期待しています！
「AWSでセキュリティをここまで高められる〜PCI DSS運用もAWSで〜」 by cloudpack 吉田 真吾さん @yoshidashingo
2003年創業当時のiretさんのオフィス(古い一軒家)という衝撃的な写真からスタートした吉田さんのお話は、PCI DSSに対応したシステムをAWSで構築する際の要点についてお話頂きました。
バッドノウハウとしてELBのログを取得する方法(経路の途中にReverse Proxyを挟めてログを取得しているがSPOFになっている、今はELBでアクセスログが取得出来るようになったので不要になるかも知れない)、AWS管理コンソールのログを取得する方法(こちらもReverse Proxy経由で接続していた、東京リージョンでCloudTrailが使えるようになれば不要になるかも知れない)などをご紹介頂きました。苦労が垣間見えて良いお話でした。
後半はリザーブドインスタンスについてのお話。オンデマンドインスタンスとリザーブドインスタンスを購入した場合の費用比較をグラフでご説明頂きました。会場がざわついていましたが(笑)やはりEC2の新タイプのリリースなどを考えるに、3年ではなく1年で購入されている方が多いようでした。
LT
「FluentdとAWSを使ったログ運用」 by 泉谷 圭佑さん
「Node.js でS3にアクセスしてみよう」 by 蛭田 聡司さん
「opsworks本番前提でopsworksを使わないで開発する話」 by 荒木 靖宏さん
まとめ
2月に延期になった時にとても残念に思っていたので、リベンジに参加出来て良かったです。良いイベントでした。スタッフの皆さん、講演者の皆さん、ありがとうございました！
14
