読者です 読者をやめる 読者になる 読者になる

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

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

  • メッセージにメタ情報が付加できるようになった(メッセージ内にメタ情報を埋め込む必要がなくなった)
  • 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でどうデータを見せるか
    • ビジネスロジックに注力!