Awsをりようしよう

『 AWSの開発・サービス』？

AWS良かった点

サーバーの調達が簡単

• スペックアップが簡単–『根拠の薄いスペック見積もり』必要無し！–使用状況に応じたスペックに変更できる–サービスイン時の突発的なスパイクに対応できる（諦める必要が無い！）

–インフラの用意に時間を取らない–開発着手が容易–『困ったら増やせばいい』がキーワード

ノウハウが多い

• とりあえず頭をつかえばなんとかなる– Amazonが用意している APIでどうにかなる

–利用者が多い！– AWS先駆者の知恵がネットの海に転がっている

–処理ロジックに専念できる！–『 AWSを使う』事で増加する工数は思ったより少ない

なんだかんだで Linux

• RDS・ ErastiCache・ Route53など提供されているサービスは多いが、 Linuxサービスを AWSが提供しているだけ–元のサービスを理解していれば、互換性のあるミドルウェアは見つかる

–きちんと環境を構築すれば、社内開発環境⇒AWSへの移行はさほど問題ない

安い

• Route53や ErastiCache等、 AWSが新規サービスしたものは軒並み利用料金が安い– EC2で自分でお守りをするより「安く」て「安定している」ため、お客様と握り直す必要が無い

–チャレンジに対する、コストの壁が薄い

操作が簡単

• GUI＆ビジュアライズ–基本的な操作は GUIで完結できる (CUIを

WEBラッパーしているので、コマンドライン操作ももちろん出来る）

–負荷状態等がカジュアルに統計化されているため、判断しやすい

–みんなだいすきオートスケールはフル CUIですが…

New Relicがタダ

• なんと驚き NewRelicがタダ– EC2ユーザーは Standard Editionが無料！– 24USD/month⇒0USD/month!!–性能監視だけじゃなく、 PHP性能監視もバッチリ (Rubyとかもあります）

– SlowQueryや、外部 APIとの連携部分、エラー部分の洗い出しも出来る！

–内部に api proxyを立てて監視してるっぽい…

AWSイケてない点

重量課金制

• 月額費用は、使ってみなければ判らない– 事前見積したスペックで良いのか？はサービスインしないと判らない

– 特にRDSは上振れしがち（Multi-AZ、ReadReplica…）

– 『可変するコストリスクを誰が背負うのか』をお客様ときちんと握る

– 『プログラム』は機能が増えなければ運用工数は増加しないが、『インフラ』は使うほど費用がかかるという当たり前の考えを持つ（逆もまた然り…）

– さらに為替レートも考慮しないと…

レスポンスが悪い

• RDSや ErastiCacheのリロードが結構時間がかかる–そもそもあまりやらないから意味ないという話もありますが…

– RDSのスペック変更時には５～１０分程度の停止を覚悟する

–サービス停止についてお客様と握っておく– EC2→RDS不通時の、メンテナンス画面自動化等は必要なものとして開発費用に

RDSがイケてない

• 『 AWSを使う＝将来的なスペックアップを期待』という業務要件に対し、 RDS(MySQL)が単一負荷ポイントに– 『何故 RDBMSに尋ねなければイケナイのか？』を自問し、必要なければ NoSQL

– 無理ならシャーディングや erasticache対応を– 『 RDBMSで動くから良い』という考えは、のちのちのアキレス腱

– 『負荷が増えてきたら考えよう』は、サービス・テスト工数に押しつぶされて手遅れ

SESがイケてない

• 『 AWSからメールを出す』と簡単に考えない–スパム対策で、 AWSがメールを出す事にとても慎重になっている

–メール発送処理が遅い（３～４秒 /通）–メール処理が多重化するとハマるので、『キューイング⇒発送処理』を大前提に考える

過負荷が変

• オンプレミスと異なり、外的要因で負荷が変動する– J-Meter等でクライアントを増加させても、右肩上がりの負荷にならない

–計測タイミングを変動させると、負荷が変動する（ 3倍強のブレが出ることも…）

–『サーバーの負荷』ではなく、『 AWSが対外的に計測した負荷』がスケールの基準

※補足ELB自体がオートスケールされるので、 ELBを暖気運転させる必要ありAmazonに申請すると暖気してくれますよ

監視がイケてない

• ディスク使用量とかメモリ使用量とかデフォルトで監視できない！– これが判らないと、スケールが判断できない…– CloudWatchのカスタムメトリクスを使えば出来る

– サーバーが自己監視⇒ CloudWatchに自己申告– 逆に言えば自己申告した値はなんでも監視できるので、DBから拾ってきた値とかも監視できる

– なんだかんだで作りこみが面倒

オートスケール運用…

• 夢のオートスケールはそんなに簡単じゃない…– 負荷上昇⇒オートスケール開始⇒サービスに参加までのタイムラグをどうするか

– ベストプラクティスは無い！– そもそも『最低限の性能でサービスを展開して、価格を抑えたい』という要求とのトレードオフ

– オートスケールがイケてないなら、でかいサーバーで待ち構えれば良い！…だけ…

– 『オートスケールしたい』なら、『オートスケール中どうするか（どうなるか？）』をお客様と認識を合わせる

– 今まで諦めていた部分をオートスケールで拾えるようになったのだから、マイナスと考えない！

AWS時代を生き抜くために

事前のにぎり

• 『サーバー費用は変動する！』を前提に、保守費や運用費を考える

• 早期開始、早期撤退ができる事が AWSの利点

• 『 AWSは安い』は幻想。• 『サービスの成長に見合ったインフラを、早急に容易出来る』が正解。

• HW障害という突発的リスクがなくなるのも利点

設計・開発

• 幅広いかつ成長する AWSサービスを勉強して、一つでも多く AWSサービスを利用する（…方が絶対楽出来る＝費用減）

• 1台の EC2・ RDSに何個もサービスを入れるという考えは AWSに即していない

• 『スケール出来るポイントをどう分割するか』がポイント

• スタティックドキュメントは S3に配置• 「 EC2≠WEB」「 EC2＝ AP」

開発

• なにはともあれキューイング• 非同期化処理前提で開発を進める• テストは少人数、ユーザーははるか多数• 『バッチ処理 (＝統計処理 )』という考えを改める⇒ RedShift、 Elastic MapReduce

• DNSベースアクセス (さらば IPベース )

運用

• 『オートスケール』＝1. 『サーバー立ち上げ』2. 『ソースを最新にデプロイ』3. 『サービス起動』

• 機会損失時間はデプロイ時間と一緒• つまり『デプロイは高速に』＝『 APサーバーはミニマムに』という事

• サーバーは即時捨てられる事を前提に、ローカルに重要なログを残さない！

以上