JAWS-UG KANSAIに参加しました

AWSのinternalなサービスの組み合わせや、サードパーティのexternalなツールによるオートメーション、をベースとした事例の紹介を始め、AWSの各サービスの説明。 あえてEC2を使わない方向でのフルマネージ。

コスパ良く理解できて思っていた以上の収穫あり。知ってることも知らないこともとりあえず全部メモ。

S3&CloudSearch

AWSストレージサービスの比較

  • S3
    • 安価・高耐久性・オンライン(1GB/約4円)
    • 5TBまで
  • Glacier
    • 超安価・高耐久性・コールド(1GB/約1円)
    • 一回入れると取り出すまでに5,6時間かかる（テープデバイス）
  • StorageGateway
    • ディスクとして使いやすくなる（オンプレでStorageGatewayのVM置いてS3を使う）
  • EBS
    • ブロックデバイス

S3

  • バケット＝ドメイン
  • オブジェクト（ファイル）
    • イレブン・ナインの耐久性
  • キー
    • オブジェクトに一意
    • ディレクトリ構造に見えるが単なるフラットな表現

  • 冗長度合いにより少し安くなる（基本は3つのレプリカ）
  • APIリクエストごとに料金が異なる
    • POST, PUT, LIST, COPY
    • GETはちょい安い

  • アウトバウンドのみ有料
  • 別リージョンへの取り出しは、少し割安

CloudSearch

ELB (Elastic Load Balancing)

  • ELBにドメインを振る
  • Internal ELB(VPC内のみ)もできる（ウェブサーバ -> ELB -> アプリケーションサーバ など）
  • ELBのHealthCheckをトリガとして、ツールによってシステムの状態をチェックし、OKならHTTP200を返す
  • EC2が全て障害なら、ELBはOutOfServiceになり、外部に障害を知らせることができる

  • ELBでSSL終端できる
  • スティッキーセッションにより、接続元によってバックエンドサーバを固定できる（デフォルトは無効）

  • ZABBIXと連携して障害通知・障害回避
  • TagNameの導入
  • スケールには時間がかかるため、暖気運転（Pre-warming）を申請しておくことにより（エンタープライズ必要）、スケールした状態で運用できる

リクエスト

  • 荷重ラウンドロビンは欲しい
  • OutOfServiceになったら切り離して再接続する必要があるが、HealthCheckで復旧してほしい

ElastiCache

  • Memcached

    • 全てメモリ上
    • LRUで削除

  • Redis

    • HDDにも書き込める
    • valueにはリスト・ハッシュも使える
    • timeoutで削除

用途

  • ウェブのセッション情報の管理
  • 同じようなデータを使いまわす
  • Cloud Watchでモニタリング、APIで取得できる
  • サーバのCPU使用率、メモリ量、I/Oのバイト数
  • get/set/Hit数, キャッシュ数・接続数、削除数、maxmemoryの制限で排除されたキー数、など
  • これらをZABBIXに食わせて、メール通知や可視化

RDS for Aurora

  • 現在プレビュー中なので情報には一部推測が入ります
  • MySQL 5.6互換
  • ストレージ容量が自動的に拡張
  • RDSの5番目のDBエンジン（MySQL/Oracle/Microsoft SQL Server/Postgres）
  • 既存AWSサービス上で、SQL/Transaction/Caching/Logging/Storage を分離するもの？

  • SQLを複数のDBサーバで実行するパターン
  • Sharding = shared nothing によってストレージを分けるパターン
  • Storage部分だけを共有するパターン（共有ストレージ型分散）

  • DynamoDB/SWF/Route53/S3 とかを使って、SQL/TransactionとCaching/Logging/Storage を分離？

  • 分散I/Oの鍵はQuorum
    • 書き込み：6台中、4台に書けた時点でOKを返す（その後残りの2台に書く）
    • 読み込み：6台中、3台から同じ値が返った時点でOK

  • CachingはメモリだけではなくSSDも使っている（公式情報）
  • 自動拡張により、ストレージフルにならない（64TBまで）
  • Cachingはプロセスが分離されているので、DBサーバを再起動してもキャッシュはとばない（SSD使ってるようなのでマシン再起動でもとばない？）

SES

  • メール送信サーバの代行サービス
  • Sandbox環境で登録した人しか送受信できない環境で試す
  • プロダクション環境は誰でも・誰にでも送受信できる

SPF認証

  • Route53にちゃんとIPアドレスの逆引きホスト名が登録される

DKIM電子署名

  • ハードバウンス
    • アドレスがない・受信拒否
    • サプレッションリスト（リージョンごとにあるため全ユーザで共有される）に登録される（14日間 or 削除依頼）
  • ソフトバンス
    • メースボックスがいっぱい・一時的な問題

SQS

  • メッセージの順序は保証されない
  • １度以上（最低１度）のメッセージ到達を保証
  • 優先度付けキューなどを構築

  • メッセージにメタ情報が付加できるようになった（メッセージ内にメタ情報を埋め込む必要がなくなった）
  • JavaのJMSでSQSがサポートされた

No EC2

CloudAutomator

  • リージョン間自動DR（Disaster Recovery）などなど
  • heroku/SendGrid 使ってる
  • 基本EC2は使っていない
  • スライド P.57

SWF

  • SQSの上位互換
  • デサイダーとアクティビティ（複数構築が可能）
  • キューはそれぞれにある
  • 各言語のSDKで利用可能

Kinesis

  • リアルタイムデータストリーム処理

    • Endpointにデータを投げる
    • Shardという入れ物にデータがばらける
    • それをAppが取得する

  • LambdaがKinesisに対応している（データの入力対してFunctionが起動）

Shard

  • 一時的な入れ物
  • Partition Key(256Byte) : Data Body(50KByte)
  • KeyによってShardが決まる
  • 24時間でデータは消える
  • 何回でも読み出せる（のでキューではない）

  • リアルタイムアプリと蓄積アプリ、同じデータを扱える
  • Write 1Mbps, Read 2Mbps

  • Shardを増やせば良い
  • コストはShardの数とデータの容量
  • サイジング（必要な容量）とPartition Keyの選択（分散の戦略）が重要
  • CloudWatchで入力データの速度を見て、Shardの数をダイナミックに増減できる
  • データを並べ替えることにより、入力された順序で取得できる

KCL

  • ライブラリ
  • APIだとどこまで読み込んだかを管理する必要がある
  • Shardに対してWorkerを起動してくれる
  • DynamoにWorkerがどこまで処理を受け取ったかを保存している

  • Kinesisないと、ELBのバックにEC2、Auto Scaleでサーバ数を制御
    • データを確実に受け取って処理する機構を作らないといけない
  • Kinesisは確実にデータを受け取り24時間以内は3つのAZに保存されていることが保証される
  • Kinesis + Lambda + DynamoDB
    • データがきたらLambdaがKickして加工したデータをDynamoDBに保存
    • あとはEC2やELBでどうデータを見せるか
    • ビジネスロジックに注力！