この記事は公開から1年以上が経過しています。内容が古い場合があるのでご注意下さい。

今回は、JAWS-UG Osaka 第10回勉強会の勉強会に参加です。

登壇された方の内容を当日メモとして列記していきます。
カッコ( )は私の感想です。

AWSクラウドで コスト削減できる理由

アマゾンデータサービスジャパン大谷さん

  • AWSは、これまでに40回くらい値下げしている
  • たくさん使うと割安で、コスト割引がスケールする

ここまではよく聞く話

嘘のようなよくある話

とあるシステムで費用を見積もったら、オンプレより1.7倍高くなったよ。

  • 構成を見てみると、「すべてをEC2で見積もっている」
  • LB、DNS、DB、バックアップ、VPNを全部EC2でサーバ作ってる。。。
  • さらにDRで同じものをシンガポールにも。

合計で120万/月になった! 「オンプレ脳!!」

EC2だけじゃなく、マネージドサービスをうまく使おう!

  • LBはELBで
    • 負荷が高くなるとスケールするし、冗長。(これは暖気させることもできますな。)
  • バックアップはS3に。
  • DNSはRoute53
  • Mailは配信だけということだったのでSESで。
  • VPNはVPCで。
  • ディスクはエフェメラルに。
  • 並列に並べてるWebサーバとかは、オートスケーリングで最小数化。
  • DRのシンガポールのシステムは常に動いている必要がないので、CloudFormationで、必要時に作成することに。

この時点で45万円/月に。

インスタンスはリザーブドにして、最終的に25万円/月になった。

利用していない検証機、開発機とかは使ってなかったら停止しておく。

まとめ

  • EC2ばっかりに頼らない。
  • 利用していない検証機、開発機とかは使ってなかったら停止しておく。
  • リザーブド、スポットインスタンスをうまく活用
  • エンジニアでもコストから構成考えよう。「見積もりは営業の仕事で、俺の仕事じゃない?」
    • クラウド設計では、エンジニアもコストのことも考えないといけないです。

microインスタンスを使い倒す+アルファ

サーバーワークス桶谷さん

サーバワークス知ってる人?

  • 挙手が少ない。意外と少ない?
  • 興味があれば、「脱藩なう」とつぶやく。
  • このURLで簡単ですよ。「bit.ly/swx20140130」 (取り扱い注意!)

本題

  • t1.microはネットワークパフォーマンスが一番低い。
    「非常に低」という表記になっている。
  • 料金は、t1.micro×3台でm1.smallくらい($0.088)
  • CPUはスモールよりもいい。最大2
  • 通常は低バックグラウンドレベル スモールの1/5
  • 短期スパイク (バースト)
  • バースト時は、smallよりも上位になる。10秒前後。長くて13~14秒くらい。
  • クールタイムはまちまち。

活用ポイント

  • バーストをうまく活かすことがポイント
  • 10秒以内に処理を終わらせる
  • 頻繁に発生しない処理。クールタイム後に終わるように。
  • もしもの時に遅れが許容される処理を担当させる。
  • リアルタイム性は無理ということを理解しておく。
  • メモリ消費が少ない処理
  • MicroでWindowsはメモリ容量的にも厳しい
  • ネットワークをあまり使用させない。

結局のところ、

  1. 総じて制限多くて使えない。
  2. お試しで使ってね、というアマゾンからの公式見解もあるので。。。

チューニングしたらどうか

  • アプリエンジニアの得意分野
  • 最初からt1.micro使うことを想定した設計で作るといいのでは?
  • 他のAWSサービスを活用しよう(ec2だけじゃなく、cloudfront,S3,route53・・・。)
  • ぶっちゃけ、サーバーワークスさんでは、アプリレイヤやってないからよくわからん。とのこと。

使いどころ(妄想で)

  • 複数インスタンスで分散処理
  • メモリ節約
  • ネットワークアクセス減らす
  • 障害発生時にロールバック、リトライ時は最初から処理させる。
  • 長時間かかる場合は、Stateを保存して次のインスタンスに
    • 火縄銃の3段攻撃みたいなイメージ。
    • 次々と他のマシンへ処理を移す的な?

実際にはどう使うか

サービスでt1.micro利用している事例はほぼゼロ

  • POC
  • 評価目的
  • メンテ時の踏み台

事例

網元AMI

  • 各インスタンスサイズに合わせてWordpressが最適化されている。
  • bitnamiと網元AMIだと100倍以上の性能比がある。
  • WordPressで、320リクエスト/秒のをt1.microで実現
  • 実際に見るとかなり軽い、というかめっちゃはやい
  • ぶっちゃけ、これつくる自信ない。
  • デジタルキューブさん、マジすげー。

網元AMIの詳細はコチラ

(今度試してみよう。)

プラスアルファの部分

安く使うって手段。aws自体が手段。
じゃあ目的は?
目的は、コストを抑えるため

  • DevOps
  • 自動化
  • これで、構築、運用リソース削減、時間の削減
  • その浮いたリソース、コストを別のことに利用できる。

(おっしゃるとおり、私がAWS好きなのは、こういうところ。)

最後に

3/15日って、何の日か知ってる?

  • 私(桶谷さん)の誕生日です。
  • ちなみに、同日に新宿でjawsdaysやるらしいですよ。
  • 前夜祭もあるそうです。私(桶谷さん)の誕生日のために!

という、Jawsdaysのご案内。

  • 会場は笑い声はなく、ダダ滑りな雰囲気。
  • 個人的にはツボったネタw 「インパク知」なネタ。

まとめ

  • t1.microでもチューニングすれば使えるけど、費用対効果も薄い。
  • サービスが大きくなってきたら、あんまり頑張ってt1.microチューンするより、smallとかに移したほうが逆にコストは下がるでしょう。

当日資料はこちら

サービスの活用と海外リージョンの利用

NRIネットコム佐々木さん

先人たちの知恵を借りましょう

EC2使ったら負け

  • EC2上でのミドル構築にも工数(お金)かかる。
  • 可用性、スケーラビリティもEC2だけで確保するのは大変。

一般的は利用されるサービスとしては、EC2,RDSが7割くらい。
活用としては、EC2よりも他のサービスも使おう。

定番サービス

S3ホスティング

  • 3万ページビュー260円/月

Route53

  • どんなに頑張っても1ドル内に収まるだろう。(1ドメイン$0.5/月 + 最初の10億クエリで、100万クエリ毎に$0.5/月)
  • これ以上のリクエストは99%のドメインで出ない。

SES

  • バウンスの処理に注意
  • 一定上届かないメールがあるとアマゾン側からペナルティあり。
    (アドレスクリーニング必須。めんどくさがっちゃだめよ。)

CloudFront

  • EC2+ELBだとEC2の数に性能が依存しちゃうので、CloudFrontをうまく使おう

BillingAlert

  • これで万が一のために、金額超過のアラート通知させよう。
    (使ってるぜー!)

Trusted Advisor

  • コスト削減できるポイント教えてくれる。
  • ただし、ビジネスサポート必要。100ドルとかかかるから。
    (俺も使いたいけどビジネスサポートなんて結んでないからつかえね。)

日本リージョンが一番高い(高かった)

  • アメリカの50%くらい高い
  • インスタンスの部分は一番高い
  • Tokyoリージョンは税込みだから高いらしい。
  • 他のクラウドサービスやオンプレに比べたら安いからいいんじゃね。
  • バックアップなら、海外リージョンも検討 シンガポールとか。
  • レイテンシの関係ない処理は海外リージョンを検討するといい。
  • バージニアが一番安い

まとめ

サービスの活用と海外リージョン安いよ、ってこと

当日資料はこちら

AWSをより安く使うテクニック

チャットワーク藤原さん

  • サーバエンジニアとして仕事してます。
  • JAWSUGコアメンバー
  • プレミアムサポート好き
  • DIRECT OBJECT UPLOADのCDPが好き

過去の失敗例

S3を大量の小さなファイルのストレージとして利用

  • 事例 ログのメインストレージとして利用。
  • 収集サーバが時分割して、収集元ごとにログを分割してS3に保存

課金例

  • GET PUTで桁が違う
  • GET は「1万」リクエストあたり$0.004
  • PUT は「1千」リクエストあたり$0.005 (COPY,POST,LISTも)
  • ファイルはできるだけ大きい単位で保存。
  • chunkしない場合のMaxサイズは5TB。

サポート契約

他のAWSでサポート契約していても、サポート契約してないAWSアカウントでは、AWSサポート受けられない。

過去の成功例

一括決済

(使ってるぜー。)
(TAG設定でもっと詳しく見れる。一括決済とは話は違うけど。)
(PDFで明細をメールで飛ばすことも可能で、利用している)

早すぎるリザーブドインスタンスの利用は避ける

はじめは大きめのインスタンス。負荷状況みつつダウンサイジング。JMeterとか使って決めます。
長期的なパフォーマンスデータの取得、確認。

  • CloudWatch、NewRelic、Munin使ってます。
  • CloudWatchは2週間分しか取れない。
  • NewRelicには、Serverプラグイン、CloudWatchプラグインもある。
  • Muninもカスタム項目で使ってる。

C3インスタンス

  • M1.largeからC3.xlargeで課金が半分。CPUは2倍以上。
    (供給がおっついてないのでは?大丈夫なんかなぁ?)
    (サービスとして使うのは・・まだ一抹の不安が。。)
    (このあたりでだんだん腹が減ってきた。。。)

インスタンスの節約

  • Jenkinsでcron設定して、シェルでstop/start
  • これで土日はサーバを止めるとかして節約。

スケジューリングベースのオートスケール

  • 夜間、土日の負荷が少ない時はオートスケールの最低台数を減らす
  • 平日昼間は、負荷が上昇する前に最低台数を増やす
    • これで費用を25%?減らしてる。
    • 突発的な負荷状況は、CloudWathcのアラームベースのオートスケールで対処。
    • スケジューリングベースのオートスケールはマネジメントコンソールでは、まだ出来ない。(残念)
    • オートスケール起動時に最新のコードがデプロイされるようにしないといけないよね、とかオートスケールも色々気をつけようね。

はじめての討ち入り

ディーワークス西島さん

  • JAWS-UG沖縄の人!!
  • 大阪ー沖縄以外と安いですよ。ピーチで。

(ピーチさんってAWS使ってないんだよな。ピーチさんのサイトかなんかで書いてあった気が。)
(これ。http://www.kagoya.jp/case/peach.html )

必要なとき、必要なだけ

  • ジャストインタイム
  • 初期費用なんていらない
  • 使った分だけ従量課金
  • 思い立った瞬間から使える
    • AWSは、ほぼこの原則に従っている

例外もある。

  • CloudFrontの独自証明書は1日単位課金だけど高い
  • WorkSpacesは月額課金
  • 従量課金なので、システムがいくらかかっているかわかる
  • CloudWatchでモニタしてグラフ化。
  • 自分で独自の値を追加できる
  • CloudWatchは、データ保存期間が2週間。

コストを下げるには?

  • そもそも使わない、パフォーマンスを抑える
  • EC2使うと負け
  • DynamoDBなら、使わないときはスループット小さくていい
    • 読み込み、書き込みのスループットに対して課金されるので。
    • EMRの話で、EMR使ってる人いない・・。

(俺もちょろんと触っただけで、よく知らん・・・。)

当日の資料はコチラ

「リザーブドキングスライム」をやっつけて一撃レベルアップ!

CloudPack石田さん

リザーブドインスタンス

  • 1,3年の予約金を前払い。
  • 利用具合により選択できる
  • 最初に払った分だけ、月額が抑えられる。3種類に分かれる
  • 大体3年間使うことが多いから、リザーブドのほうがいいよ。

注意点

  • リザーブドは、「インスタンス相当の利用権を購入する」ということ。

例えば、
オンデマンドインスタンス3台の場合に、2台リザーブ購入したら、
現在の3台のうち2台がリザーブインスタンスに変更される。
3台が1台になったら、2つ買ったリザーブのうち、1つがもったいないことになる。

  • リザーブインスタンスのタイプ変更可能
    • 一定の条件あり。
  • 同じインスタンスファミリーだと合体したり、分裂したりできる。

当日の資料はコチラ

R3 institute 金春さん

  • 今後の年間スケジュール
  • JAWS DAYS 2014の案内
  • 前夜祭の案内
    • 前夜祭の後、バスがチャーターされるので新宿まで行けます。
    • 途中で大江戸温泉寄るから、お風呂も安心。

リンク

感想

個人的に知らなかったこととかを踏まえてまとめると、

  • EC2は出来る限り使わず、Route53やS3とかのマネージドサービスを使おう
  • 常時稼働が必要でなければ、こまめに停止しよう
  • スケージュルベースのオートスケーリングを活用しよう
  • t1.microはサービスとして利用するのは控えよう。メンテ時の踏み台とかに使おう
  • t1.microを頑張ってチューンするより、m1.small使うほうが結果的にコストが安くなると思われる
  • 用途に応じて、海外リージョン使えばさらに安くできる
  • 費用項目は、似た処理でも異なることがあるので、事前によく確認しておこう
  • サービスによっては、例外的な料金体系になっていることもあるので注意しよう

という感じでした。

JAWS-UG Osaka では初めて100人を超える参加者になったとのことで、今年は大阪でも、さらにAWS関係が盛り上がってきそうです。

関連記事:

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です