絶品ゆどうふのタレ

ふと気づいたことを綴るだけのメモ

AWS Summit 2015 - Day2 - AWS System Operation Deep Dive

AWS

  • AWS 酒徳さん

  • AWS上での運用をどうやって行くべきか

システム運用で考えるポイント

  • クラウドだからといって考える事の基本は同じ
  • Monitoring
    • 死活監視
    • キャパシティ監視
  • Logging
    • 誰が、いつ、どのような変更をしたのか
  • Configuration
    • 構成管理
    • Chef / Puppetとかの個別の構成ではなく、システム全体の構成の話

Monitoring

  • CloudWatch

    • AWSのリソース監視
    • 死活・性能・ログ監視
    • メンテナンスイベント
    • 他にも、課金状況の監視など

  • 何がオンプレと違うか？

    • モニタリングのマネージドサービス
      • 可用性を考える必要がない
    • データの持ち方
      • データポイントとしてデータを丸ごとごそっと持っている
        • 個々のメトリクス情報として持っているわけではない
      • いろんな切り口でモニタリングデキる
        • Metrics / Namespace / Dimension などという組み合わせによって絞り込んでみていく
      • これらを統計値として見る
        • sum / max/ min など

  • CLIから情報を引っこ抜いてきて情報を持ってくることができる

CloudWatchと監視ツールの線引と連携

  • 責任共有モデルの範囲か否か、で分けたりするのがひとつの手

    • カスタムメトリクスを使えば、CloudWatchだけで監視することもできる

  • 定期メンテナンスの時にアラートを出したくない、とか

  • オンプレミスの環境と組み合わせながら、やっていったりするのが効率が良い

  • Mackerel / DatadogなどでSaaSで監視してしまうのも手

  • Sensuを使ったモニタリング例

    • RappidMQを使ってスケール
    • SSLを使った通信でセキュアに

  • CloudWatch Log

    • エージェントがLogをendpointに送る
    • 1回あたりのpushは32KB まで
      • それを超えるとログがトランケートされる
      • そのメッセージしか残らない
      • ログのカット等をアプリ側で実装する必要がある
    • 対応しているローテーション
      • rename and re-create
      • copy and truncate
      • ceate common-patterned file
        • poort毎に異なるファイルに書き込まれるようなパターンのログは追えない
    • ログの転送設定
      • file_fingerprint_lines
        • デフォルトでは1
        • 1行目は必ず同じになる！という場合には上手く動かないので、この辺を変える必要がある

Logging

  • CloudTrail

    • APIの発行とAWSリソースの呼び出しをCloudTrailでJSONのログとして保存

  • 利用ケース

    • 検知
      • 何かあったらすぐ知りたい
    • 検索
      • かつて何があったか調査したい
    • 可視化
      • トレンド

  • CloudWatch Logs Metrics Filterの利用

    • CloudTrailのログをCloudWatch Logsにどんどん投げ込む
    • CloudFormationのテンプレートが公開されている

  • CloudTrail API Activity Lookup

    • 直近7日間のログが閲覧できる
    • ただし、CloudTrailのサポートするサービスをすべて見れる、というわけではない。注意

  • CloudSearch, Lambdaとの連携

    • S3にup されたCloudTrailのログをLambdaが検知してCloudSearchに流す

  • ElasticSearch, Kibana, Lambdaの連携

    • S3に入ったのをLabmdaが検知し、それをElasticsearchに流し込んでKibanaで表示

  • splunkでもとかでも可視化可能

  • 短期、中期、長期の目的に依って使い分ける

Configuration

  • AWS Config

    • 構成変更を記録して、変更の記録
      • ヒストリとして残す
      • 今の状態をスナップショットとしてのこす

  • リレーションシップ

    • relationship
      • 今の変更点が、どんなものに影響を及ぼすかをJSONに記録される
      • EBSが3つから4つになった場合の差分が記録されたり
    • セキュリティグループの変更の影響が、どれくらいのインスタンスに影響するかを見ることができる

  • Logstorage

まとめ

  • もちろん、今回のもので全てできるわけではない
  • サードパーティー製のツールも使いつつ、上手く組み合わせて運用していく

AWS Summit 2015 - Day2 - ネットワークDeep Dive

AWS
  • AWS 吉田さん

VPCベストプラクティス

Marketplaceを活用する

  • ファイアウォールやロードバランサ、WAF、ルータ、ネットワーク高速化などの製品が利用可能
  • EC2のMarketplaceから検索

VPC Peeringを利用する

  • 2つのVPCの間でネットワークをpeeringする
    • 企業間コラボレーション
      • お互いの会社がAWSをつかっていれば、簡単にネットワーク接続が可能
      • セキュリティグループで必要な通信だけに絞ることもできる
      • 新しいEDI
    • セキュリティ昨日の共有例
      • Proxy / WAFをセキュリティチームが共有サービスとしてメンテ
      • アプリケーションチームのVPCは直接インターネットにアクセスできず、VPC Peeringでセキュリティチームレイヤにつないでアクセス

VPCのルーティングとセキュリティ

  • VPCのルーティングはすべてサブネット単位のルートテーブルに基づく

  • IPレベルでの接続性確保が目的

  • 主なルーティングのエントリ

    • VPC内のCIDR: local
    • default route: 0.0.0.0 NAT
    • オンプレへのトラフィックはVGW: 192.168.0.0/16とか
    • 通信したいVPCのネットワークアドレスへのルーティングは Peering Connectionへルーティング

  • ACLとセキュリティグループ

    • ACL: ブラックリスト型
      • ステートレスなので、戻りも明示する
      • ネットワーク構築時に不要な通信を禁止
    • セキュリティグループ: ホワイトリスト型
      • ステートフルなので、戻りを考慮する必要はない
      • 運用時に必要な通信を許可

  • ベストプラクティス例

    1. ルーティングですべての到達性を確保
    2. 全体ポリシーで不必要な通信をACLで構築時に禁止
    3. 個別に必要な通信をセキュリティグループで許可

VPCエンドポイント

  • S3へのアクセスは、以前はNATインスタンスなどを通す必要があった

    • シングルポイントだった
    • それを解決

  • private subnetに設定することで、中から直接外にアクセスできるようになる

  • エンドポイントポリシー

    • VPCエンドポイントに直接IAMポリシーを設定可能

  • 既存からの移行

    • 既存のNAT構成の中にVPC endpointのルーティングを追加すれば、ロンゲストマッチに依ってVPC endpointが優先される

  • 注意点

    • リージョンをまたいで通信することはできない
    • VPN / AWS DirectConnect / VPC PeeringなどからVPC endpointは使えない

Direct connect ベストプラクティス

  • BGPの動作
    • ルートにBGP除く聖地は付与しない
    • お客様ルータのBGP俗世地を評価
    • ロードシェアリング可能
      • マルチパス有効
    • プライベート接続ではVPCのプレフィックスを広告
    • パブリックだとAWSクラウド内のプレフィックスを広告
    • BFDが有効

回線フェイルオーバーの高速化

  • BGPでは、障害検知が遅くてフェイルオーバーが遅いことが問題になりやすい

  • BFD

    • ミリ秒レベルで対向ルーター同士でBFDパケットを送受信
    • なくなった場合に障害検知
    • 非常に高速なフェイルオーバー
    • リアルタイム性の高いアプリケーションの場合は設定を
    • 推奨

  • KeepaliveとHoldtime

    • BGPの機能の一部
    • keepaliveを指定した間隔で送受信
    • 単純にこのHoldtimeのデフォルト値を短くする
      • 自分のるーたの設定値を低い値にすれば、AWS側のるーたもその低い方を採用する仕組み

経路の冗長化

  • Active/Standby

    • 片方だけVPNという接続をしてる人もいる
    • BGPの属性値によってどのPathを選択するかを設定
    • のぼりとくだりは違う属性値で管理されている
      • AS Path Prepend
      • オンプレからの送信はLocal Pre...を優先

  • 注意点

    • どちらの回線がActiveなのかをきちんと管理
    • 上りと下りのトラフィックを意識

  • Active/Active

    • マルチパスによって、複数経路に対してロードバランスして送信する
    • Maxmmum Path
    • AWSのルータではマルチパスが有効になっている

  • 注意点

    • 回線の切断時、正常な回線のトラフィック・帯域溢れに注意
      • マルチパスのペアをもう一つ用意したり
      • Active/Standbyにしたり

占有型と共有型

  • DirectConnectの構成

    • 物理線(Connection)の中にVLAN(Virtual interface)を構成してる

  • 占有型と共有型

    • 占有型: Connection単位
    • 共有型: Virtual Interface
      • 1契約につき1接続
      • たくさんVPC接続する場合は、その数分だけ契約する
    • どれくらい必要になるのかをよく見て、契約を判断

  • キャリア閉域網の共有型の例

ネットワークのコード化

  • ネットワークにフォーカスしたコード化

  • CloudFormation

    • JSONテンプレートを用意して構築
    • updateも可能
  • AWS CLI / SDK

CloudFormationの例

  • VPC / Subnetの構成例

  • サンプルテンプレートを元に使ったり、サードパーティーツールで便利に書ける

  • JSONを編集 -> CloudFormationでロード

  • CloudFormerを利用したテンプレート作成

    • 既存の構成を元にテンプレート作成

AWS CLI / SDK

  • シェルのコマンドを使う

  • VPC作成の例

  • PythonのSDKなども可能

  • タグに寄る動的NAT制御の例

    • NATインスタンス起動時に自分自身の情報を元に判定してルートテーブルを更新する

さいごに

AWS Summit 2015 - Day2 - 今日から始められる、機械学習！Amazon Machine Learningのご紹介

AWS
  • AWS 今井さん

機械学習の例

  • スパムメール判定

    • 二値判定、二項分類
    • 教師データ
    • 別の方法でSpam判定ずみのデータを元に学習
    • それを元に判定

  • 商品カテゴリの判定

    • マルチクラス分類
    • この商品はどのカテゴリのものか？

  • 明日の売上の予測

    • 回帰分析
    • 過去のデータ群を教師データとする
    • それを元にモデルの線を引き、明日の条件に最も合う条件で予測する

  • スマートのアプリケーションを作るには

    • 機械学習に強くて
    • R / Python場合によってはHadoop / Sparkに明るい
    • 特定分野のビジネス経験が必要

  • これは大変

  • なので、Amazon Machine Learning

Amazon Machine Learning

  • Amazonがアルゴリズムを提供
  • パッケージサービスとして提供
    • ワークフローが予め提供されている
    • MLは教師あり学習に対応している

  • スケーラビリティ

  • 取り扱えるモデルとアルゴリズム

    • 二項分類
      • ロジスティック回帰
    • 多クラス分類
    • 回帰分析
      • 線形回帰

  • 予測手法

    • バッチ予測
      • S3にあるデータをまとめて予測を実施
    • リアルタイム予測
      • データを一件ずつAPIを使って投げて予測

AMLの使い方

  • 教師用・評価用データを準備
    • S3 / Redshift / RDS for MySQLをデータソースとして利用可能
    • CSV形式のデータ
  • 教師データからモデルを作成
  • モデルの品質評価
    • 評価用のデータを流してテスト
    • 7割の教師データを使って学習、3割を使って品質評価をする(自動で分けてくれる)
    • Scoreの許容度をどこにするかをグラフィカルに設定できる！
    • 制度に満足できない場合は、教師データを精査して繰り返す
  • 実際の予測に使う

料金

  • 分析、トレーニング、評価
  • バッチ予測
    • $0.10/1000

  • リアルタイム予測

    • $0.10/1000
    • +モデル10MBあたり$0.001/h

  • リージョンはus-east-1のみ

    • どのS3リージョ運のデータでも大丈夫

利用例

  • 広告の不正クリック検出

    • 教師データ: 実際のクリックログ
    • 問題の分類: 二項分類
    • 出力: ログごとに不正かどうかチェック

  • 広告のリダイレクタの中でAPIを叩けば、その場で不正かどうかの判定が可能

  • デモグラ推定

    • 教師データ: でもグラがわかっているユーザーの行動ログ
    • 問題の分類: 多クラス分類
    • 出力: ユーザーを行動ログからデモグラ判定

  • デモグラに基づいたレコメンデーション

    • 教師データ:購入履歴にデモグラをマッピングされたもの
    • 問題の分類: 多クラス分類
    • 出力: ユーザーのデモグラを入力し、F1なので商品カテゴリこれがいい、みたいな出力

  • 写真からの判定

    • この後デモ

アーキテクチャへの組み込み

  • S3からデータを出し、MLにかけてまたS3へ
  • Redshiftをデータソースとして扱い、S3へ
  • リアルタイム予測
  • DynamoDB StreamsやLambdaを使って MLにかける

AML説明まとめ

  • 機械学習の導入が用意になり、すぐにでもデータ分析が始められる

AMLデモ

  • 榎並さん

  • 顔写真から特定の人物判定

    • 顔写真をグレースケールにしたビットマップ
      • 各ピクセルの明度を数値化して、大きな配列にする
    • 二項分類

  • 構成

    • OpenCVで顔部分を検出
    • 写真をグレースケールに

  • トレーニングデータについて

    • 前処理の部分は自分で用意する必要はある

流れ

  • トレーニングデータCSVをS3にアップロード
  • AMLのコンソールからCSVを指定
    • CSVの最後の部分が二項分類の値だよね(binaryだよね)というのを予測してくれる
  • 自動で学習と品質評価をしてくれる
    • アップロードデータの3割を自動で評価データにしてくれる
  • 出た結果を元に、許容度を設定

  • ML real time の設定をすると、リアルタイム予測ができるようになる

  • APIで正しい写真を渡すと、正解フラグとスコアが帰ってくる

    • 間違った写真でも同様

まとめ

  • 機械学習のプロフェッショナル用のサービス、という趣よりも、詳しくないデベロッパーでもすぐ始められるサービス

AWS Summit 2015 - Day2 - keynote

AWS
  • 昨日と同じ話は省略

AWS Mobile Service

  • Mobile SDK

    • Mobileの中から直接AWSにアクセスすることが出来る
    • モバイルの中で使いやすいSDK
      • ネットワークが途切れていても大丈夫な作り、バッテリーにやさしい作り

  • Mobile SDK for Unity

    • Machine Learningのサポート
    • Lambdaのサポート

  • Cognite

    • ユーザー認証
    • データ同期
    • セキュリティ

  • Cogniteのアップデート

  • Mobile Analytics

    • 短期間でデータを取得
    • MAU/DAU/セッション/リテンションレポート
    • ユーザーのイベントをトラッキング

  • Mobile Analyticsアップデート

    • S3 / RedShiftへのエクスポート

  • SNS Push Notifications

    • CloudWatchの通知の配信ステータス
    • SNSでのLabmdaの起動

  • 成功は突然、予期しないタイミングで来る

    • その時のスケーラビリティ

  • Labmda

    • イベント駆動型バックエンド
    • 実行時だけの100ms単位の課金
    • モバイル単位の課金不要

  • Lambdaの新たなイベントソース

    • SNSからの通知をトリガーにLambdaを起動
    • CloudWatch
    • Cogniteデータが変更されるごとにLabmdaを実行
  • LambdaのJava対応！

  • LabmdaとCogniteが東京リージョン対応

  • IoT

    • Dash.lyの事例
    • ODB-2ポートのデータをKinesisに送って解析

Kawamotoさん

  • スイスアーミーナイフとRDBは似てる

  • 色々な機能を持っている

    • だが、拡張が難しい

  • Dynamo

  • 基板となるインフラ運用にはまだ課題があった

  • 一元化したサービスの運用

  • キーワードはマネージドサービス

  • DynamoDBのリリース

  • Dynamoはモバイル・IoTにも効果的

  • DynamoDB Stream

    • DBの更新情報を外部アプリケーションから利用可能
    • Device -> Dynamo -> Stream -> lambda -> Redshift/SNS/Machine Learningなどの連携

Community HERO 横田さん

  • スシローとガリバーの事例

  • スシロー

    • 店舗データをKinesis + Redshift
    • これをAmazon Machine Learningにかける試み

  • ガリバー

    • モバイル業務アプリ
    • Cognite ベースで認証
    • モバイルからLabmda -> Dynamo -> Labmda -> SNSで通知

  • ほとんどEC2を使っていない

  • 最初にAWSを使おうと決意すると、まずオンプレからEC2に移そうとかんがえる
  • 次のステップで出てくるのがこれらのクラウドネイティブなサービス
    • マネージドサービスを組み合わせることで、運用・構築をもっと楽に

Gene

  • モバイルのもう一つのアプローチ
  • エンタープライズモビリティ
    • WorkSpaces
    • WorkDocs
    • WorkMail

  • すべてがモバイルデバイス対応

  • Amazon WorkDocsの日本語UI・東京リージョン

Wrap up

  • 10月にAWS re:Invent

AWS Summit 2015 - Day1 行ってきたまとめ

AWS

AWS Summit 2015 に行ってきた！

とりあえず自分の参加したセッションの内容を全部記事化した(一つに書くには長すぎた)ので、 まとめ用Index記事をつくったよ！(｀・ω・´)

雑感

  • 新しいプロダクトも1年でずいぶん増えたイメージがあるし、ソリューションアーキテクトの人たち総じて話のクオリティ高い印象あって、AWSほんといろんな面ですごいな、という感じ。
  • 色々話聞いてくると、色々実験したくなった！
  • 印象強かったのは「もはやクラウドは先進的な人たちのものではなくなった」というkeynoteでの長崎さんの話と、パネルセッションのnaoya・大場さんの「正解など誰にも分からないが、現状は正しく認識して対処する必要がある」という話。
    • ホントそうだな、と思ったし、クラウドはもう常識として消費されきっていて、その上で次のステージを模索してく時代になってってるのかな、と思った。

AWS Summit 2015 - Day1 - EBSパフォーマンスベンチマーク2015

AWS
  • AWS 小林さん

EBSのおさらい

  • ブロックレベルのストレージ
  • スナップショットを使ってバックアップ
  • 暗号化

  • 99.999%の可用性

  • 特徴

    • 容量は1G単位で16TBまで
      • マグネティックは1TBまで
    • AZごとに独立
    • スナップショットから任意のAZに復元可能

  • 1つのEBSを複数のインスタンスから参照することはできない

    • 付け替えは可能

アーキテクチャ

  • AZ内で複数のHWにレプリケートしている

ボリュームタイプ

  • ３種類からユースケースに合わせて
    • General Purpose SSD
    • Provisoned IOPS SSD
    • Magnetic
  • Snapshotをとって復元することで、ボリュームタイプを変更可能

汎用SSD

  • デフォルト
    • 費用対効果の高いディスク
  • 一時的に3000IOPSになるバースト機能を備えている

  • 1GBあたり3IOPSを常時確保(ベースパフォーマンス)

    • 容量が1000GB以下の場合は3000IOPSに一時的に引き上げるバーストが可能
      • たとえばOS起動時にはバーストさせて一気に起動させたり
    • 最大は10,000 IOPSまで上昇
      • 3334GBを超えたところで、常時10000IOPS

  • バーストの継続時間はIOクレジットの残高で決まる

    • バーストが発生するとクレジットを消費
    • 下回ったら時間とともにクレジットが溜まっていく

  • 容量とスループット

    • 容量依存でスループットが上がる
    • 170GB以下では128MB/s
    • 徐々に上がる
    • 214GB以上では常時160MB/s

Provisioned IOPS

  • SSDを超える性能
  • 99.99%の時間について、指定IOPSの+-10%の範囲で性能発揮する
  • 最大20000IOPSまで
  • 最大320MB/s(1280IOPS以上)
    • IOPS設定値依存

Magnetic

  • 磁気ディスク
    • かつてのデフォルト
  • コスト安
  • 1TBまで
  • 平均100IOPS
  • 最大数百IOPSまでバーストできる場合がある
  • IOPSの命令回数ベースで課金

パフォーマンスの律速要素

EC2インスタンス側のスループット

  • EBS-Optimized オプションを有効に

  • インスタンスタイプごとに上限値があるので、そこに到達していないか

    • CloudWatchの Volume Read/Write Bytesの合計値で判断

  • 上限に達している場合は、インスタンスタイプを大きくする

  • EBS最適化をOnにすると、EBSへのアクセス回線をインターネットの帯域と別に確保する

EBS側のIO性能を改善する

  • EBS側の実績値を確認する
    • CloudWatchの Volume Read/Write Opsを参照
    • OS から見てもいい
  • 上限に達していたばあいは、ボリュームの上限を改善

EBS側のスループットを改善する

  • 個々のボリュームのスループットを確認する
    • CloudWatchの Volume Read/Write Bytesを確認
  • 上限に達していた場合は、ボリュームタイプとスループットを確認

事前ウォーミング

  • EBS各ブロックの初回アクセスに限り、IOPSが5~50%低下する
    • 性能測定など
  • プレウォーミングを実施すると、回避できる

  • 実運用時には事前ウォーミング不可能な場合もある

  • 実行方法

RAID構成

ベンチマーク検証

  • それぞれのボリュームタイプについて、仕様通りの性能が出ていることを確認

  • RAIDによってそれを超えた性能が出せることをチェック

  • 構成

    • c3.8xlarge
    • 2015.03
    • xfs
    • EBSはpre-warmingずみ

  • このへんはもうグラフ見ないと伝えづらい。。。

  • こまかいブロック(8KB, 16KB)の場合はIOPSが高まって、そちらで頭を打つ
  • 大きなブロック(4MB)の場合は、IOPSの上限の前に、スループットが頭を打ってしまう
  • 大きなブロックの場合、IOPS値を大きく取り過ぎてしまうと費用がもったいない場合があるので、注意

インスタンスストアとEBS

  • もっと性能が欲しい場合は、インスタンスストアを使う
  • 追加ストアなしで使えるディスク
  • スループットはEBSとは独立している
  • インスタンスを止めるとデータは消える
    • 再起動では消えない
  • アプリケーションが使う一時的なデータの置き場所や分散システムのデータ置き場

ベンチマークをしてみる

ボリュームの暗号化

  • AES-256
  • ハードウェア機能を使って暗号化するので、パフォーマンスに影響しない
    • ほんと？というのを確認

  • fioで負荷をかけてiostat/vmstatでチェック

  • 実際にグラフを見ると、IOPSはほぼ変わらない

  • CPU使用率も殆ど差がない

典型的な構成例

  • 小さいデータへのアクセスが多い場合

    • 必要IOPSが得られるようにEBSを構成
    • ブロックサイズが小さければ、スループットがボトルネックになることは少ない
    • 本来必要な容量よりも多く取ることで、IOPSを稼ぐ
    • 単一で難しければRAID 0

  • 大きいデータへのアクセスが多い場合

    • IOPSよりもスループットを重視
    • シーケンシャルな場合も同様
    • 無駄にIOPSを高めないようにするほうが、コストを抑えられる

  • 低コストなストレージが必要な場合

    • アクセス頻度が低い・パフォーマンスが不要な場合はマグネティック

  • 極めて高いIOが必要な場合

    • インスタンスストアを利用する
    • OSやアプリケーションが必要とする大事なデータはEBSを利用する

まとめ

AWS Summit 2015 - Day1 - 自動デプロイ

AWS
  • Elastic Beanstalk, Opsworks, CodeDeploy, CloudFormation

  • AWS 舟崎さん

  • どう使い分けたらいいか、どう組み合わせるか

Intro

  • EC2 / ELB / RDS / S3 を組み合わせる事が非常に多い

  • 設計としては多いが、デプロイを自動化する点まで考えられていることは少ない

    • デプロイの自動化がなぜ必要か、はこのセッションの対象ではない。その前提で話す。

  • デプロイを考える際のフェーズ

    • コーディング
    • ビルド
    • テスト
    • デプロイ
    • プロビジョン(リソース生成)
    • モニタリング

  • Code Commit

  • Code Pipeline

    • コードをデプロイする際の処理・ワークフローを自動化させる
    • まだAWSとしてリリースされてない

  • Elastic Beanstalk / OpsWorks

    • Deploy / Provision / Monitor
  • Code Deploy
    • Deploy のみ
  • CloudFormation
    • Provisionのみ
  • Cloud Watch
    • 監視

Elastic Beanstalk

  • 定番構成の構築・アプリデプロイの自動化サービス

Opsworks

  • 多様なアーキテクチャをサポートするデプロイ・管理サービス
    • chefのレシピを使ってデプロイや運用タスクを自動化可能
    • ライフサイクルイベントに従った動的な構成の変更
    • 継続的な構成管理

Code Deploy

  • アプリケーションのデプロイに特化
    • agentをインストールして管理。オンプレミスも管理可能
    • グループ内に一度にデプロイしたり１台ずつデプロイしたり、といった処理が可能

CloudFormation

  • JSON形式のテンプレートを元に、AWSリソースの環境構築を自動化

Wordpressをデプロイする手法

  • wordpressのデプロイを題材に、４つのサービスを比較

    • コンフィグも自動生成したり。

  • 構成イメージ

    • GitHubからコードをデプロイ
    • ELB - EC2 - RDS + S3(wordpress plugin)

  • どれがベストか、という話をするわけではない。

  • 自分達の要件に合うかを検討する材料にしてください。

Beanstalk

  • 起動の流れ

    • ElasticBeanstalkがインスタンスを起動
    • 中にHost Managerが入っていて、それが通信

  • GitHubと連携

    • zipかwarのパッケージにしてEBにupload
    • cliツールに、それを補助してくれるコマンドがある
      • 昔はgitと連携するgitなんとかっていうCLIコマンドがあった
      • aws cli v3からはeb deployというのが該当コマンド
  • 順次バッチ処理でのデプロイ
    • 一度に(1台/25%/全部)にデプロイ
      • というのを調整できる
    • Blue Green Deploy なんかもあり(今回は違う)
  • 環境のカスタマイズ
    • AMIを作りなおさなくても、Elastic Beanstalk Configuration fileで動作中のコンテナをカスタマイズできる
    • 環境設定のRolling Update
      • インスタンスの置換えを伴う操作を一部ずつ実行
      • 裏ではCloudFormationのupdate policyという機能で実現してる

OpsWorks

  • 起動の流れ

    • PHP App Serverレイヤーを作成
    • レイヤー内にインスタンスを追加
    • 起動したinstanceの中にagentがはいる

  • OpsWorksに指示を出すと、Agentがポーリングに合わせてAppを取得

    • デプロイJSON を書いておけば、それをchefのレシピの中から呼び出せる

  • レシピの実行タイミングについて

    • ライフサイクルイベント
      • Setup - ここはbuiltinのレシピが動く
      • Configure
      • Deploy
      • Undeploy
      • Shutdown
    • いつどれが呼ばれる？
      • Setup - 起動直後に、該当インスタンスで呼ばれる
      • Deploy - そのあと、deployイベントが走る
      • Configure - deployが終わると、「全インスタンス」にconfigureイベントが走る

  • Cookbookの更新

    • リポジトリにPush
    • カスタムCookbookの適用を指示
    • ポーリングのタイミングで適用される

Code Deploy

  • サーバは起動しないので、自分でエージェントを入れる

  • Depoyの流れ

    • Githubに入れるソース内にappspec.yamlというファイルを入れておく
    • Config内容
      • どれをデプロイするか？
      • どうやってデプロイするか？
      • どこにデプロイするか？
  • 環境のカスタマイズ
    • appspec.ymlのなかに、hooksを設定できる
    • shellscriptの実行が可能
  • CloudFormation都の連携
    • インスタンスの生成をしたいときには連携させるといい
    • 現状は、CodeDeployのエージェントをインストールしたインスタンスを建てるのにCloudFormationをつかうといい

CloudFormation

  • CloudFormation template(JSON)の中にプロビジョニングとデプロイの内容を書いておく
  • 頻繁にデプロイしないのであれば、CloudFormationでやってしまうのがいい
    • 頻繁にやるなら、プロビジョニングだけを担当させる方がいい

まとめ

  • それぞれ簡単にできるが、手順が異なる
  • 要件に合わせて活用してください