@thorikiriのてょりっき

@thorikiriがWebとかAndroidとかの技術ネタや本を読んだブログです

トップ > aws

AWS Summit 2012 に行ってきたよ クラウドデザインパターン#8　CDP アンチパターン編

event aws

9月の14日と15日にAWS Summitに行って来ました。メモの量が大量すぎて、まとめられてないです。
とりあえずは、面白かったCDP アンチパターン編を投下しておこうと思います。

クラウドデザインパターン CDP アンチパターン編

  • アンチパターン
  • 負荷テスト急発進アンチパターン
    • ELBはELBのあるように動作
    • ELBのオートスケール特性を知らない
    • ELBを使ったWebサービス等で性能を測るための試験を行う際に、バックエンドサーバには余裕があるのに、クライアントには503が届く。
    • ELBは負荷分散の為だけにある。なので、その下にあるサーバに対して行えば良いのでは？
    • テスト前にプレミアムサポートに相談して、負荷をかけてくださいとお願いしてください。
  • CloudFrontを使わないアンチパターン
    • 日本国内向けだけでも使えます
    • 配信先が日本だけなので要らないと思っている
    • キャッシュ設定を嫌う
    • HTTPのアクセスピーク時に帯域が律速に。CPUやディスクに余裕があるのにサービス出来ない。
    • S3のレスポンス（200−500ms）が遅いと文句を言う。まぁ、早くはないですけどね。
    • CloudFrontで出来ますよ。
    • オリジンサーバのキャッシュ制御を適切に設定する。CloudFrontが見て適切に処理してくれる。
  • リージョン勘違いアンチパターン
    • リージョンは独立している
    • リージョン選択を意識していない
    • S3のバケットをUS-Standardにつくっていしまい、転送速度や遅延に悩む
    • 一旦消さないと作り直せない。他を構築している時に、別のところに作ったことを忘れている。
    • 不要なサービス、インスタンスの放置
      • 使わなかったら消してください
    • sshの鍵がなくてログイン出来なくなったりします
    • マネージメントコンソールではなく、よく使うサービスをリージョン名を含めてブックマークしておきましょう。忘れません。
    • 明細を時々チェックしましょう。課金アラートを設定する。
    • S3バケットは作り直すこと。
      • COPYすればバケット間で直接移行出来る
  • 消化不良アンチパターン
    • つまみ食いサイコーです。
    • 全機能を使おうとして消化不良になる。
    • AutoScallingを無理やり使おうとする。そもそも必要なのか考えよう。
      • マネージメントコンソールから出来ないよ。止めても止めても立ち上がる。
    • ENIを設定したもののOSの設定をしない。
    • システムが動くことが最優先であって、AWSを使う機能のが目的ではない
    • AWSが提供する機能は、各社の要求の最大公約数なので、必要でないものもあるよ
  • インフラ塩漬けアンチパターン
    • 構築したきり、インフラの見直しをしない
    • 昔の知識で止まっていると、見直しをしない。
    • キャパシティの過不足も放置したまま利用している
    • 一時しのぎで選んだサービスをそのまま使い続けている
    • サービスは四半期に1度は見直すこと。
    • 新サービスや新機能が助けになることがあるので、AWSの営業に相談してみよう。
  • ノーガードアンチパターン
    • 作戦ならばよし
    • セキュリティグループやNACLをめんどくさがって全開にしてしまう
    • 思わぬ攻撃をうけてから初めて気がつく
    • 本番環境、開発環境は分離しましょう
    • 開発環境でノーガードにする分には問題ない。それはノーガードではいいですけどね。
    • 簡単な方法は、アカウントを分ける。VPCを分ける。セキュリティグループを明示的にわかるようにする。
    • Trusted Advisorによってサポートも受けられる（月100万払う人たち向け）
  • オンプレキャパプラアンチパターン
    • システムの利用予定期間内ずっと使えるだけのキャパシティを確保
    • 5年先に必要だからといって
      • EBSのボリュームを最大1TB確保する
      • Provisioned IOPSを1000にする
      • 大きすぎるインスタンスを使用する
    • 使用するリソースは順次拡大していきましょう、そうするような設計にしましょう。
    • リソースは定期的に見直すこと
  • S3勘違いアンチパターン
    • S3を共有ストレージ、ブロックストレージとして使ってしまう。
    • S3をFUSE等を使ってマウントして、ログ、webコンテンツをS3に配置して共有しようとする
    • S3にデータベースファイルを配置してしまう
    • S3はブロックストレージではない
    • S3でWebコンテンツを共有するなら、S3をWebサーバとして利用する。そして、CloudFrontを使う。
  • EC2 一神教アンチパターン
    • EC2は自由
    • AWSの古い知識で止まってしまっている
    • サーバを調達して、その上で作る方法に慣れ親しみすぎている
    • 目的ごとにEC2を用意するので、インスタンス数が増える
    • 可用性の担保にも手間がかかる
    • Route53、RDS、S3、ELBなどEC2以外のサービスを活用しましょう。
    • 可用性の確保がわりと安く出来る
  • 片寄せアンチパターン
    • マルチアベイラビリティゾーンがAWSの基本
    • AZ間の通信料金を気にする
    • 複数のAZ運用のノウハウを単に知らない
    • 普段は大丈夫であるが、トラブル時にあわてることになってしまう
    • ELB、RDSなど複数AZ便利に使うサービスを導入しましょう
  • IPアドレス信者アンチパターン
    • 4倍に増えたらどうするんでしょ？
    • IPアドレス固定環境に慣れている
    • 全てのインスタンスにEIPをつけてしまう
    • ELBでCNAMEのFQCONを使わずIPアドレスを指定する
    • RDSのエンドポイントを使わない
    • VPCでプライベートアドレスが固定なことを知らない。
    • EC2以外のサービスを使うときはIPアドレスで参照するものではないことを理解する。
      • スケールアウトするので、IPでは管理しないでね。
    • 利点を理解しましょう
  • トラフィック心配性アンチパターン
    • AWSに向かうトラフィックは関係ありません
    • トラフィック、リクエストによる利益とコストの見積りができない
    • 料金青天井だと心配しすぎる
    • ログを確認しない
    • Billing Alarm機能の利用
    • システムの特性をまずは洗いだしておく
    • 料金の相談ができる会社の利用→サーバーワークスさんとか
  • 机上の空論アンチパターン
    • JUST DO IT
    • サーバ発注して、システムデプロイ、納品の硬直したループにはまっている
    • 動作確認をしない
    • 事例のキャパシティプランニングに時間をかけすぎる
    • ともかく、小さく試してみることが大事である。
  • まとめ
    • システムの規模に合わせた可用性を持つシステムを構築かのうにしてください。
    • 低コストで耐障害性の高いシスエムをつくろう。

Amazon Web Services クラウドデザインパターン 設計ガイド を読んだよ

book aws

Amazon Web Services クラウドデザインパターン 設計ガイド

Amazon Web Services クラウドデザインパターン 設計ガイド

ちょっと前になりますが、読み終えました。
Cloud Design Patternの本ですね。現在48パターンあって、CDP48となっているそうです。ああ、そうですか。
第1章では、その48個のパターンそれぞれについての解説が説明されています。これをひとつひとつ読むだけでも面白いですね。コストの視点でどう考えるかとか、熟練者からのアドバイスが受けられるでしょう。
第2章では、画像や動画などのコンテンツ配信サイト、Eコマースサイト、キャンペーンサイトの3つのシナリオにそって、そのサイトの成長具合やらなんやらに沿ったパターンの適用例が書かれています。読み物としても非常に面白いですね。
付録として、それぞれのサービスについて解説もあります。どんなサービスがあるかわからない場合には、まずはこちらを流し読んでから本編に入るのがいいかも知れません。詳細に書かれている訳ではないので、イメージ出来る人ならそのまま本編読めばいいと思います。
これから、AWSを使ってアプリを構築していくような人は、全体を俯瞰するためにも知っておくべきなんだろうなと思います。
しかしながら、AWSに限ったことではないですが、日々進化していっている分野です。この本が夜に出てからも新しいアーカイブストレージサービスが出たりしています。それぞれでキャッチアップしていく必要があるかと思います。
本家のWikiや、Facebookページで継続的に情報収集しなければなりませんね。

JAWS-UG勉強会 第12回 に行ってきました #jawsug

event aws

夜勤明けに寝て起きて行ってきました。疲れが取れてないので、途中で集中力が途切れてしまってちょっと残念でした。
今回はクラウドDBについてフォーカスしているようですね。
いつも通りメモをアップしておきます。

アジェンダ紹介、JAWS-UG 紹介

AWS最新アップデート AWS堀内さん(@horiuchi)

  • 前フリ
    • 試用期間から正社員になりました
    • 6月後半にJAWS九州ツアーやりますよ
  • 今年3月からアップデート内容サマリ
    • 3月
      • 主要サービス値下げしました
      • ミディアムインスタンスが出来ました
      • 64bitOSに対応した
      • WebコンソールにSSHクライアント対応
      • IAMのよる詳細リリース管理が可能
      • IAM利用料レポート閲覧アカウント
      • RDSの自動アップデート35日まで出来るように
      • BeanstalkでPHPをサポートしました
      • リージョンまたがるルーティングが可能になりました
      • EBSのボリューム監視
      • CloudFrontのFlashMediaサポート。
    • 4月
      • DynamoDB BatchWriteItem機能
      • Beanstalkの東京リージョン
      • DynamoDBのAsia Pasific
      • CloudFormationでVPCを構築可能
      • WindowsServer2008R2サポートなど
    • 5月
      • EC2 MS SQLServer提供
      • RDS for ORacleがMulti-AZサポート
      • RDS SQLServerを選択可能
      • Beanstalkが.NETサポート
      • StrageGatewayのAPI提供可能
      • Billing Alert利用料金の可視化
      • CloudFrontが動的コンテンツサポート
      • SimpleMAilServiceがドメイン検証機能を追加
      • RDSのリードレプリカがVPCでも作成可能
      • ELBマネジメントコンソールからSSLの設定が可能
      • 北カルフォルニアとオレゴンでIPv6サポート
      • DynamoDBのテーブル操作をマネジメントコンソールから出来るようになった
      • EC2のVMをエクスポート可能
      • RDS for OracleでOracle Enterprise Manager（OEM）が利用可能
  • 宣伝
    • ハンズオンサポートします。AWSは触ってみるのが一番です。
    • 企画すればクーポン持参してくれます。
    • サミット東京 9月13日14日 お台場来てね！
    • AWS re:Invent2012 in ラスベガス11月27日28日29日 メアド登録出来るので、お願いします。
      • ツアー企画します。

AWS Raju Gulabani　VP, Database Services 講演

  • 全般的な話
    • AWSは2006年からスタート。スタートアップ相手だったけど、今では大手が使ってるよ。
      • 日本でも大手が使ってるよ。
      • それ以外でも、アメリカでは国の機関が使ってますよ。お気に入りは財務省だね。お金を扱ってるところがだよ。
      • 本当にセキュアなの？国家機関使ってるんだぜ、国防総省とか。セキュアだぜ！
      • たくさんのリージョンとEdgeロケーションがあるよ。
      • コスト削減と速度がAmazonで出来たように、AWSでもそうだよね、今はそれ以上のものを開発者に提供出来るよ。
      • ソフトウェア、アプリケーション開発に変革をもたらしたよ。
    • 初めに、セキュリティがセキュアであって欲しいと思うよね、今では今までのエンタープライズよりセキュアだぜ。
      • FISMAって言うアメリカでもっとも厳しいセキュリティ企画を満たしてるよ。
    • 分散型アーキテクチャがすげー簡単になったよ。
  • データベースサービス
    • データベースサービスは個人的にもお気に入りだ。複数のオプションがあるよ。
    • AmazonRDS+ElastiCache
      • YesSQL！RDBに使い慣れている人たち向けだね。
      • RDSはManagedServiceでお好みのRDBが使えるぜ。
      • MySQLからはじまってOracle、SQLServerもだよ。
      • ElastiCacheもManagedServiceでMemcacheのことだよね。
    • SQL派じゃない人向けにもNoSQLがあるよ。
      • DynamoDBだね。
      • 新しい新世代の大規模なスケーラビリティを必要とするソーシャルゲーム向けだね。
  • YesSQLについて
    • DBで課題なのは、インストールとか、バッチとかパフォーマンスチューニングとか。けっこうめんどい。
    • スケーリングのためのコードとか、パフォーマンスとチューニングとか。
    • Amazon RDSはそういう作業が要らないんだね。
    • Amazon RDSは完全に管理されたサービスなので、開発者は展開してスケールして、アプリケーションの構築をすればいいんだよ。MySQL、Oracle、SQLServerが選べるよ。
  • ハイパフォーマンスのためにオプション
    • PushButtonScaling：管理コンソールでボタンを押すことで小さなDBから大きなDBに透けるアップ出来る
    • ReadReplicas：リードのスループットを上げるために、Readのレプリカを増やして負荷分散するよ。
    • ElastiCache：memcacheを使って、キャッシュして使い回してスループットを上げるよ。
    • Multi-AZ：ユニークです。１つのAZからもう一つのAZにレプリケーションをとっていく。
  • レプリケーションの取り方
  • どれが適切なの？
    • 考え方は簡単。基幹系だったら、RDS Multi-AZを使おう。
    • 読み込みが大事だったら、RDS Readレプリカ（ロジカル、非同期）
    • 信頼性を高めたいなら、両方合わせて使うのがいいよ。
  • ビッグデータについて
    • ビッグデータとは？たくさんのユーザ、様々なデバイスがある。
    • 結果として、毎秒あたりのデータが爆発的に増えていますよ。
    • 大量のデータを格納して、処理しなければならないね。
    • アプリ層とデータベース層があるよね。アプリ層を増やして、データベースは増強する。でもさらに増えたらデータベースはパンクするね。時間の問題だ。
    • なので、NoSQLの存在が求められるようになるわけですね。
    • NoSQLは、そもそもスケーラビリティが求められているんだよ。
    • AmazonはNoSQLのパイオニアですよ。
  • DynamoDB
    • DynamoDBは高速でスケーラビリティがあるよ。
    • 管理が簡単、LowLatency、ReservedCapacity、Unlimited Potential Storage and Throughput
    • DynamoDBは極めて高速である。1桁ミリセカンドのレイテンシーです。
    • データが完全にSSDに保存されているよ。
    • レイテンシーは一貫しているよ。同時アクセス数でも。データの量が１Gでも1テラでも関係ないよ。
    • 高信頼性だよ。データは自動的にAZにレプリカが同期されるよ。
    • １つのAZが落ちても自動的に別のAZにフェイルオーバーするよ。アプリは停止せずにね。
    • スループットのプロビジョニング。テーブル生成時に値段を決める。APIで変更出来るよ。
  • Hadoopインフラとの統合について
    • S3にCSVで格納されていた場合、それをDynamoDBにロードしたい場合は、EMRでパラレルにDynamoDBに1ステートメントの実行命令で出来る。
    • 逆に分析したい場合も逆にやればいいよ。
  • DynamoDB利用のユースケース
    • AmazonCloudDrive：メタデータをDynamoDBを、オブジェクトをS3に
      • インフラに触れること無く、簡単に開発出来るのがDynamoDBのメリットである。
    • Shazam：スーパーボウルと広告連動する。億を超える人達のデータを格納しなければならない。
      • 1秒間に何十万のリクエストをさばける。EMR/DynamoDBのコネクターを利用して解析したよ。
      • 設計から環境構築まで3日で作ったよ。
  • QA
    • DynamoDBの設計は？
      • RDBならERモデルだよね。モデリングテクニックは存在しない。新しい技術だからね。
      • プライマリーキーを選んでシングルアトリビュートとする。
      • データの全てが1つに集合しないようにすること。まぁ、アプリによって色々あるよ。
    • 他のNoSQLと比べての優位性
      • DynamoDBはCassandraと違ってServiceだと言うことが違うね。
      • なので、インフラ面を気にする必要がないってことだ。

マイネットジャパン

  • 事例
    • カードバトル型のGREEのゲーム作りました。
    • 2012/1/5から開発して、5/23にリリースしました。
    • DBはDynamoDBオンリーです。ランキング集計でEMRを使ってます。
  • ソーシャルゲーム
    • ソーシャルゲームはNoSQLと相性が良い。
    • ユーザIDで検索することが多いので。キーをユーザIDにすれば良いだけです。
    • ソーシャルゲームではアップデートが激しいので、RDBだとALTER TABLEで死ねる。
  • DynamoDBで出来ること
    • 条件付きアップデート 楽観ロックは必須 ただし、等式での条件だけ
    • インクリメント。デクリメントで更新前、更新後の値が取れる
    • トランザクションでは、リランナブル設計。2回実行しても問題ないように設計する。
    • 更新済みならスキップするようにする。
    • 失敗したらキューから取得してもういっかいやる。成功したらキューから消す。
    • 基本5フェーズで実装する。入力チェックエラー、書込み処理開始、書込み処理、。。。。
    • レンジキーと言うものがある、ハッシュキー（ユーザID）＋レンジキー（範囲検索が可能な属性）
      • 開始点と検索方向とリミットで制御するよ
    • EMR連携でインデックスを作る検索方法の代替が出来る
    • SQSでリアルタイム更新インデックスを作る
    • AmazonCloudSearchが東京リージョンまだ出てないけど、コレ使えばよくなりそう。
  • バックアップは？
    • EMRでS3にエクスポート。でも一貫性は保証されない。
    • ソーシャルゲームの場合必要なし！とすることも出来るよね。
  • 苦労したうえで、得られること
    • 無制限にスケールするストレージ
    • 安心して旅行にいける権利：運用が楽！

DynamoDBを選んだ理由

集中力が途切れてしまいまして、メモってないです。ごめんなさい。
Twitterみたいなものを作るとき、MySQLだとインデックス増えて大変！ってことは覚えてます。

Klab

同じくメモってないです。ごめんなさい。
ケーラボって読むのかと思ってたけど、クラブって読むんですね。

得上(@tottokug)もSimpleDBとDynamo[DB]への愛を伝えたい

ものすごい愛を感じました。

サーバーワークス 大石さん(@ooishi)のいい話

切腹！
昨年の大震災の義援金関連で日本赤十字のサイトをAmazon上に置いた関係で、義援金受け付けるシステムを作った話。
48時間で作られたそうで、ものすごいスピード感ですね。