元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2015/06/03

「サーバにログインしない・させないサービス運用」講演メモ (AWS Summit Tokyo 2015) #AWSSummit


メモった。間違い等あるかもしれませんが、その場合はごめんなさい。


Gunosy

  • 2011.09リリース
  • 現在900万DL突破
  • エンジニアは現在26名
    • 2014.11は16名、2013.11は7名、2012.11は4名
    • クライアント+QAは5名、Web+APIまわりは5名、インフラは1名とかとか

Gunosyの開発

  • API: Golang
  • パートナー・広告主への管理画面: Rails
  • バッチ・内部向け: Django or Python
  • バージョン管理: GitHub
  • 構成管理・デプロイ: Chef (+OpsWorks)

開発の特徴

  • 小さい単位で作ってすぐ捨てる
  • マイクロサービス的な
  • 機能が増えすぎたら分割
  • メンテするよりリプレース

サーバにログインされて困る事

  • 信頼できないビルド・デプロイ
    • 開発者の手元でビルドすると、どの断面なのかわからずトラッキングできない
    • プロダクションに上がっているものが信用できない、ステージングも本当にテストしたい断面のもの?
  • 勝手に加えられる変更
    • 勝手に追加されるパッケージ
      • サーバ追加/リプレースしようとすると動かない
    • 勝手に変更されるcrontab
      • コメントアウトしたの誰?なぜ?
  • 以前はChefを使っていた
    • サーバとレシピの間に乖離がある
    • レシピを追随させる必要がある

アプリケーションのデプロイは信頼できるものである必要がある

  • 信頼できないデプロイ
    • 事故のリスク
    • 手戻りの発生
    • エンジニアの時間的・精神的負担

バージョン管理・CIツール・デプロイツールをそれぞれを導入すればよいというものではない。

全てを統合した一連のワークフローを作る事が大事。


GitHubを中心とした開発・デプロイフロー

  • Service Hookを利用し、各サービスを連携
    • GitHub, CircleCI, AWS OpsWorks
  • 各ブランチをマージする度に自動でビルド・テスト・デプロイ
    • 見える化、効率化、事故の削減
  • デプロイしたければPull Requestを作る
    • Pull Request Driven Deploy
  • OpsWorksでもデプロイ履歴は追える

どうしてもつきものなのが調査

サーバにログインして調べますか?

ブラウザから全てのサーバログを見られるように

  • ミドルウェアログ収集
    • papertrail
  • アプリケーションログ収集
    • airbrake (errbit)
    • kibana

papertrailを使って、サーバにログインがあればhipchatに流れるようにしたりとか



まとめ


「開発生産性を上げるためのデプロイ戦略」講演メモ (AWS Summit Tokyo 2015) #AWSSummit


メモった。間違い等あるかもしれませんが、その場合はごめんなさい。


デプロイとは

  • あらゆるコードやバイナリ、アセットなどの配布をデプロイと定義
  • インフラストラクチャーの構築はプロビジョニングとする

なぜデプロイに注目する必要があるのか

  • AWSのイノベーションのペース
    • 合計1000以上の新サービス、新機能をリリース
    • フィードバックループを回し続け、顧客の期待に応え続ける

Amazon.comのデプロイ

  • 平日のデプロイ間隔 11.6秒
  • 1時間あたりの最高デプロイ回数 1079回
  • 1回のデプロイで平均10000台のホストに変更を加える
  • 1回のデプロイで最大30000台のホストへの変更

Two pizzaルール

  • 1チームの大きさは、2枚のピザで全員お腹いっぱいになれる規模
  • それを保って頻繁にデプロイできるレベルに
  • 作った人が運用をやるポリシー

クロスファンクショナルチーム

各チームメンバーが何ができるかをマトリクスにして、チーム全体で必要な技術をカバーする


ポイント

  • 多くのチームが非同期にデプロイする必要
  • APIによるチーム間の疎結合化
  • デプロイの自動化と全チームでの利用

従来型のデプロイの問題点

  • 手順書がメンテナンスされない
  • 手作業で間違う
    • いままで何度もやっているはずなのに
  • 職人芸への依存
  • リリース失敗・戻しにも失敗
  • 長時間作業と失敗率の拡大
  • 結果としてコスト増大・流出
  • リリースにいつも自信を持てない
  • どんどんプロセスが重くなる
    • 失敗するとチェックを重ねる事になる、トラブルごとに増える

TPSの側面からみると、色々なムダがある。ムダを排除して本業にリソースを集中できるように。


デプロイの戦略検討のポイント

  • いつ?
  • 誰が?
  • 要件は?
    • ダウンタイムの許容度、グレースフルの必要性
  • プロセスは?
    • 承認の必要性

チームサイズ・プロダクト規模・アーキテクチャが関係


自動化の基本原則

  • 完全自動化の原則
  • 変更量最小化の原則
  • 高速完了の原則
  • 不可逆変更回避の原則
  • 成功・失敗自動判定の原則
  • 失敗時ロールバックの原則
  • デプロイパターン集約の原則

ベストプラクティス

  • バージョン管理
  • テスト自動化
  • 継続的インテグレーション

※安全な開発のためPJ初期からやるべし

※常にリリース可能な状態に保つようにする


費用対効果

  • ソフトウェアの複雑化が進行
    • 手作業で同時に複数箇所を間違えずに操作する事が困難
  • デプロイ回数はそもそもとても多い現実
    • 本番環境にだけデプロイするわけじゃない。様々な環境に何度もデプロイしているはずなので、プロセス全体をみて考える
    • 自動化しればすぐに損益分岐点を交差する
  • その他の潜在的コスト
    • 新人の教育コスト削減
    • 失敗した際に発生する損失の削減

デプロイのパターン

  • 単純デプロイ
  • サービス停止&デプロイ
  • 読み取り専用化&...
  • 機能縮退化&...
  • 半数切り離し&...
  • ブルーグリーンデプロイメント
  • カナリアリリース

AWSにおける開発系サービス

  • Code Commit
  • Code Pipeline
  • Elastic BeansTalk
  • OpsWorks
  • CodeDeploy
  • Cloud Formation
  • Cloud Watch

Sorryページへの切り替えパターン

  • ELBを手前に入れる
  • Route53によるDNSフェイルオーバー
    • TTLを考慮しないといけない

ELBのConnection Draining

  • ELBでは切り離した際、新規割り振りを中止して、処理中のリクエストが終わるまで待つ
  • タイムアウトは3600秒

その他注意ポイント

  • 処理フローの互換性の確保
    • 前バージョンから新バージョンがリクエストを受けても、処理を継続できるようにする
  • 開発環境と本番環境の相違点を確認
    • 接続先DBやパスワード、環境によって変化するもの
    • 環境変数か設定ファイルのどちらかで管理、おすすめは環境変数
    • ハードコードやAMI埋め込みは避ける

AutoScalingを使っているパターン

  • 最新のアプリケーションがデプロイされている必要がある
  • 稼働中インスタンスへのデプロイをどうするか
  • AMIをどこまで作り込むか
  • インスタンス起動時のcloud-initの活用

どんなAMIを使うか

  • 1. 全部いるAMI (デプロイすれば終わり)
    • 同一性が確保、ただしデプロイごとにAMI作り直し
  • 2. Golden Image (ライブラリやコードは起動時にとってくるとか)
    • アプリコードを取得するのみなので、扱いやすい
  • 3. 最小構成AMI (Chefとかだけ入れておいて、起動時にプロビジョニングからやる)
    • 中身は自由に変更できるが、起動処理に時間がかかる

AMI自動作成例

Jenkins+Packer+Serverspecとか


マイクロサービスでの注意点

  • サービスの後方互換性を確保する
    • 各サービスは同じタイミングでデプロイしない
    • インターフェースを変えるときは新旧両方用意しておく


まとめ


「AWSへのDCマイグレーションストラテジー」講演メモ (AWS Summit Tokyo 2015) #AWSSummit


メモった。間違い等あるかもしれませんが、その場合はごめんなさい。


何を移行するのか

  • 一部システムがAWSに向かないため移行検討が進まない
    • All or Nothingではない
    • 大多数のエンタープライズはハイブリッド型
    • 移行対象は選定が必要

  • AWS技術制約確認
    • 物理機器(USBドングル、プリンター、テープ装置、物理ストレージ装置)
    • 共有ディスク
    • ネットワーク
    • 未対応OS(RHEL4以前、Windows2000以前、AIXなど
    • ミドルウェア・パッケージ
    • 性能(CPU36コア、メモリ244GBを上回るサーバ)
  • 業務要件確認
  • コスト・移行合理性確認

どのように移行するのか

  • セキュリティポリシー
  • オンプレミスシステムとの結合度
  • ランニングコスト、移行コストを算出し、ROIを試算
  • コスト比較だけではなくAWSを使うメリットを再確認
  • 移行後のアーキテクチャ
  • 移行計画の検討
    • RTO(目標復旧時間)、RPO(目標復旧地点)は?
    • 現行環境の構成は?
    • 現行環境は目標サービスレベルを達成しているか?
    • 目標サービスレベルは本当に必要か?
  • クラウド移行時のアーキテクチャパターン
    • Rehost, Refactor, Revise, Rebuild, Replace
  • 既存のマネージドサービスすべてで使われている機能を、AWSのマネージドサービスで実現できるとは限らない
    • RDS(データサイズがRDSの最大容量を超える、DBパラメータを細かくチューニングしたい)

移行後どのように運用するのか

  • 運用変更項目の洗い出し
  • 役割分担の整理
    • AWSの権限管理
  • ガバナンス方針
    • コスト管理
    • セキュリティチェック

ケース:社内標準ガイドライン作成

  • サービスレベル・インフラ・運用の標準を定義
  • 標準ガイドラインを作成
    • サービス時間、可用性、バックアップ、災害対策、拡張性
  • サービスレベル毎にインフラ構成を定義
    • 標準インフラ構成ごとにCloudFormationテンプレートを作成

AWSへの移行方式

  • サーバの移行
    • サーバ再構築+アプリ導入(既存のオンプレミスな環境での移行イメージと同様)
    • 仮想マシンのインポート(VM ImportでOSイメージを丸ごと移行可能)
  • データの移行
    • ファイル単位、ブロックデバイス単位、ミドルウェアの機能を利用

VM ImportによるOS変更点

  • OS起動、ネットワーク接続等、AWS上で稼働するための最低限の変更が加えられる
  • CentOS 6.6での例
    • ブートローダー関連(ttyS0追加)
    • ネットワーク関連(内部DNS参照、DHCPによる取得)
    • ファイルシステム群(UUID追加)

VM Importのこれまでの課題

  • 転送に時間がかかる
  • 失敗した場合、ファイル転送からやり直し
  • 複数ボリュームの仮想マシンが移行できない
  • 同時にImporできる数が少ない

新しいVM Import API

  • EC2インスタンスを作るのではなく、AMIを作るようなイメージ
  • イメージ転送と、IMport処理を分離
  • S3にあるイメージを起点としてAMI/EBSスナップショット作成を実行
  • OVA形式への対応

オンプレミスからAWSへ接続

  • 接続方法
    • Internet
    • Internet VPN
    • DX(Public)
    • DX(Private)

※Direct Connectを使う場合、S3はVPC外にあるため、Public経由か、Privateであれば要Proxy


  • 移行時のダウンタイムをいかに短くするか
    • データ同期までの時間がシステムのダウンタイムに直結
    • 帯域を有効に使いきれる方式を取る

ファイルの移行方式

  • S3へ
    • 専用線接続を利用する
    • 大きいファイルはマルチパートアップロード
    • 並列で転送
  • EC2へ
    • ソリューションを活用(WAN高速化ソリューションを使う)

ブロックデバイスの移行

  • S3
    • VM Importを利用
    • AWS Storage Gateway
  • EC2
    • DRBD
    • DataKeeper

ミドルウェア機能を利用したデータ移行

  • バックアップ・リストア
    • 一般的に移行時間は長くなるが、十分なダウンタイムが取れる場合に利用
  • 各ミドルウェアのレプリケーション機能
    • Active Directoryなど
  • レプリケーション専用ソフトウェア
    • ライセンスが必要になるケースがある(Oracle GoldenGateなど)

データ移行時間を考慮したシステム切り替え方式の選択

  • 一括移行
  • 一括移行+差分同期
    • バックアップを使ってある断面でのシステム移行を行い、切り替え時に差分を同期
  • 並行稼働による段階的移行
    • データを同期しながら利用ユーザを徐々に移す

データ移行方式のポイント

  • 十分なネットワーク帯域を用意
  • 帯域を有効に使える移行方式を選択
  • ミドルウェアレベルでの機能が使えるか検討
  • ダウンタイムを考慮して方式を検討


まとめ


2015/06/02

「Amazon EBS パフォーマンスベンチマーク2015」講演メモ (AWS Summit Tokyo 2015) #AWSSummit


これまたメモったので、貼付けておきます。

間違い等あるかもしれませんが、その場合はごめんなさい。


Amazon EBS

  • EC2インスタンスにアタッチして使用するブロックレベルのストレージサービス
  • snapshotによりバックアップやディスクの暗号化機能を提供
  • 99.999%の可用性を備えるよう設計されている

EBSの特徴

  • 1GB単位で指定。最大16TB
    • マグネティックは最大1GB
  • AZ毎に独立、同一のAZからのみ利用可能
  • Snapshotからは任意のAZに復元・移動可能
  • EBSを複数のインスタンスから同時に使う(共有)ことはできない

アーキテクチャ

  • データはAZ内の複数のHWにレプリケートされる
  • 実態はネットワーク接続型のストレージ
  • セキュリティグループによる通信制御の対象外

ボリュームタイプ

  • ユースケースに応じて3種類から選択
    • 汎用SSD、Provisioned IOPS(SSD)、マグネティック
  • タイプに応じて性能特性や課金体系が変わってくる
  • Snapshotを経由する事で、ボリュームタイプや容量を変更できる

汎用SSD

  • デフォルトのボリュームタイプで費用対効果が高い
  • 一時的に3000IOPSまで引き上げるバースト機能を備える
  • 1GB〜16TB
  • 1GBあたり3IOPSを常時確保
  • 1TB以下の容量では、3000IOPSまでバースト、最大10000IOPS(3334GB以上のボリュームでは常時)
  • スループットは、最大160MB/s(214GB以上利用時)
    • 170GB以下では、128MB/s
  • バーストの継続時間は、I/Oクレジットの残高によって決まる
  • バーストが発生するとI/Oクレジットを消費、I/O負荷がベースパフォーマンスを下回ると、I/Oクレジットが蓄積

Provisioned IOPS(SSD) - PIOPS

  • 最もパフォーマンスの高いタイプ。1年間のうち99.9%の時間について、指定したIOPSのプラスマイナス10%の範囲の性能を発揮する。
  • 4GB〜16TB
  • 100IOPS〜20000IOPSで指定可能
  • 容量の30倍がIOPSの上限
    • 20000IOPS指定しようとすると、667GBの割当が必要
  • スループットは、320MB/s(1280IOPS以上)
    • 1IOPSあたり256KB/sのスループットを発揮する

マグネティック

  • 最もコストが安価な磁気ディスクタイプ。過去は、Standardという名称のデフォルトのボリュームタイプ
  • 1GB〜1TB
  • 平均100IOPS
  • 最大、数百IOPSへバーストできる場合がある
  • スループットは、40〜90MB/s
  • 唯一I/Oリクエスト回数による課金がある

パフォーマンスを律速する要素

  • EC2インスタンス側のスループット
  • EBS自体のI/O処理性能
  • 各EBSボリュームのスループットの上限

EC2インスタンス側のスループットを改善する

  • EBS最適化を有効にする
    • EBS最適化を有効にすることで、独立したEBS帯域を確保
    • 大きいインスタンスタイプほど使える帯域が大きい
  • インスタンスタイプによって決まるEBSスループットの上限値に到達していないか
    • CloudWatch
    • OSでiostatなど
  • 上限に達している場合は、インスタンスタイプを大きくすることで改善する

EBS側のI/O処理性能を改善する

  • EBS側の実績IOPSを確認する
    • CloudWatchとか、OSからiostatとか
  • 上限に達していればボリュームの変更を検討する
    • タイプやスペックの変更

EBSボリュームのスループットを改善

  • EBSボリュームにスループットを確認する
  • 上限に達していればボリュームの変更を検討する
    • PIOPS化する際は、平均ブロックサイズから必要値を算出

事前ウォーミング

  • EBSの各ブロックへの初回アクセス時に限り、IOPSが5%〜50%低下する
  • 事前ウォーミングを行う事で回避可能
  • 実運用時は難しいケースもあるので、要件から判断して実行可能であえば取り込む
    • Auto Scalingで起動したインスタンスなど
  • Linuxであれば、ddコマンドとかで
  • Windowsは完全フォーマットを使用

RAID構成

  • 単体のEBSのIOPSやスループットでは不足な場合、RAID構成を使う
  • RAID構成にすると、複数ボリュームのsnapshotの整合性に注意

パフォーマンス

  • c3.8xlarge
  • Amazon Linux 2015.3
  • FS: xfs
  • fio(2.15)を使用
  • 対象
    • 1.マグネティック
    • 2. 汎用SSD 3000IOPS
    • 3. 汎用SSD 10000IOPS
    • 4. PIOPS 4000IOPS
    • 5. PIOPS 20000IOPS
    • 6. 汎用SSD x6 (RAID0)

IOPS

※単位はIOPS

パターン1. 2. 3. 4. 5. 6.
8KBランダム読込2113109998040592027454634
16KBランダム読込2063066956439851899244688
8KBランダム読書3293108997540572027454717

※4MBブロックの掲載は割愛。当然IOPSは伸びない。なぜならスループットの上限が先にあたってしまうから。


スループット

※単位はMB/s

パターン1. 2. 3. 4. 5. 6.
8KBランダム読込1.724.378.031.7158.4426.8
16KBランダム読込3.247.9149.462.3296.8698.3
4MBランダム読込73.2162.2163.0317.5313.7842.2
4MBランダム読書52.5162.2163.3317.6314.4846.4

インスタンスストア

  • 追加コスト無しで、インスタンスストアが使える
  • 実体はEC2の物理ホストのローカルディスク
  • インスタンスを停止するとデータが消去される。再起動では消去しない
  • 一時的なデータ置き場や、分散FSとか

インスタンスストアの性能特性

  • 条件
    • i2.8xlarge
    • Amazon Linux 2015.3
    • FS: xfs
    • 800GB SSD x8 (RAID0)
    • fio(2.15)を使用
  • ランダム読み込みで、最大40万IOPSとEBSと比較して高いパフォーマンスを発揮
  • スループットは最大3.5GB/s
  • ランダム読み書きでも、最大35万IOPSを発揮

ボリュームの暗号化

  • AES-256による暗号化処理
  • AWS Key Management Serviceで鍵を管理
  • ハードウェア機能を使って処理するので、暗号化有無はパフォーマンスに影響しない
  • 汎用SSD(10000IOPS、20000IOPS)で、実際にパフォーマンスを計測しても、IOPS値もCPU使用率もほとんど変化無し

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

  • 必要IOPSが得られるようEBSを構成する
  • ブロックサイズが小さければ、スループットがボトルネックになることは少ない

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

  • シーケンシャルアクセスが多い場合も、IOPSよりもスループットを重視する
  • IOPSをおさえることで、費用削減が可能

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

  • アクセス頻度が低いデータやハイパフォーマンスが必要ないデータは、マグネティックに保存
  • 大容量が必要な場合は、RAID構成を取る

極めて高いI/O性能が要求される場合

  • EBSでは処理しきれないパフォーマンスが必要な場合は、インスタンスストアを利用する
  • 永続化が必要なものは可能な限り、EBSに保存する
    • インスタンスストアはStop(停止)すると、データが失われてしまう


まとめ


「Amazon RDS for Aurora Deep Dive」講演メモ (AWS Summit Tokyo 2015) #AWSSummit


メモったので、貼付けておきます。

間違い等あるかもしれませんが、その場合はごめんなさい。



  • Auroraは現在Preview中
    • 頻繁にデプロイ・機能変更が行われている
  • 今日の話の内容は6/2時点のもの

フルマネージドなDB

  • データベースを数分で作成可能
  • 自動でパッチの適用
  • 1クリックでスケールアウト
  • S3への継続的バックアップ

Amazon Aurora

  • AWSがクラウド時代にRDBを作るとするとどうなるかを1から考えた
  • エンタープライズグレードの可用性とOSSレベルのコストを両立
  • 現在はLimited Preview
  • Virginia/Oregon/Irelandリージョンで動いている
  • 5/20よりpreviewがプロダクション環境へ移行
    • Beta環境はクローズ

AuroraのPricing

  • 現在は、r3シリーズのみでの提供
  • ライセンス料金は不要
  • MySQLと100%互換なので、ロックインはない
  • インスタンス分の課金に加えて、ストレージ課金とIO課金もある

特徴

  • MySQL5.6との互換性を保つように開発されている
  • ストレージが10GBから64TBまでシームレスに拡張
  • 3AZに2つずつ、計6つのデータコピーを保持
    • S3にStreaming Backupを実施
  • VPC内に起動
  • 99.99%の可用性を実現するように設計されている

なぜ、AmazonがDBを再考したか

  • 現在のモノリシックなデータベースでは、スケールアウトさせるとコスト・可用性・柔軟性の面で問題
  • 今、データベースを再度実装するならどうするか?
    • 1970年代の方法では実装しない
    • ハイエンドデータベースの要なスピードと可用性
    • OSSデータベースのシンプルさとコスト効果の高さ
    • 利用した分だけ支払うモデル

Service Oriented Architecture

  • ログとストレージレイヤをシームレスにスケールするストレージサービスに移動
  • EC2, DynamoDB, SWFなどのAWSサービスを管理コンポーネントに採用
  • S3を利用して高い可用性でストリーミングバックアップ

キャッシュレイヤの分離

  • キャッシュをデータベースプロセス外に移動させた
  • データベースプロセスのリスタートが発生してもキャッシュが残った状態を維持可能

Auroraのストレージ

  • SSDを利用したシームレスにスケールするストレージ
  • 標準でHAを実現
    • 3AZに6つのコピー
    • 2ディスクが利用不可でも読み書き可能
  • Log Structure Storage
  • Auroraが6本のディスクへの書き込みを待たずに、少なくとも4つに書き込みが完了したらすぐに次の処理を実行
  • ホットスポットの影響を取り除き、非常に高い並列度を実現
  • ストレージはSSDベースのディスクに10GBずつのブロック内に分散して書き込まれる

ストレージの特徴

  • リードレプリカもマスタと同じストレージを参照
  • 継続的なS3への増分バックアップ
  • 自動で再ストライピング、ミラー修復、ホットスポット管理、暗号化

Log Structure Storage

  • 追記型のストレージシステム
    • 常に末尾にデータを追加していくだけ
    • GCによりデータを効率的に格納する
  • シーケンシャルに読み出す事が出来る
  • 常に最新のデータが末尾にある
  • これらの特徴によりS3への継続バックアップ・書き込み性能の向上を実現

ディスク障害の検知と修復

  • 2つのコピーに障害が起きても、読み書きに影響は無い
  • 3つのコピーに障害がおきても、読み込みは可能
  • 障害が起きても自動で修復

レプリケーション

  • Consistency - 異常を修復
  • Latency - 同期 vs 非同期レプリケーション
  • network I/Oを効率的に行う
  • Binlogによるレプリケーションではない
  • マスターへの負荷を最小限にしつつ、15台までリードレプリカを作成可能
  • 100ms以内のレプリケーション遅延
  • マスタとリードレプリカで同じディスクを共有しているため、フェイルオーバーでデータロスが無い

セキュリティ

  • データの暗号化
  • SSLを利用
  • VPCを使ったネットワーク分離
  • ノードへの直接アクセスは不可能

DBクラスタ

  • マスタとリードレプリカをひとまとめにしたもの
  • フェイルオーバーが発生しても、常にマスタを参照できるエンドポイントが1つ存在する
  • DB Parameter GroupとDB Cluster Parameter Group(クラスタ内で共通設定)がある

フェイルオーバーとリプレース

  • リードレプリカが存在する場合は、1分程度でフェイルオーバー
    • リードレプリカが存在しない場合は、10分程
    • 今後、開発が進めばもっとはやくなるかも
  • 優先的にフェイルオーバーさせるノードを1つ指定可能
    • Multi-AZ配置として、別AZで起動する
  • ノードリプレース時に新Auroraノードを起動するAZを指定可能

クラスタエンドポイント

  • Writer/Readerのセットをクラスタと呼び、クラスタで常にWriter(マスタ)を指すエンドポイントが存在する
  • 各Auroraノードはエンドポイントを持っている
  • クラスタのエンドポイントはその時のアクティブなWriterのCNAME
  • 参照は各Readerを参照する
  • 障害が起こると、別ノードが昇格し、エンドポイントの指し先が変わる

高速なデータ修復

  • Disk readの一環としてオンデマンドでredo logの適用を行う
  • 並列、分散、非同期で行われる
    • MySQLだとシングルスレッドなので時間がかかる

Streaming SnapshotとPITR

  • 各セグメントごとにS3へ継続的に増分バックアップを取得
  • パフォーマンスに影響なし
  • PITRで5分前から、Backup Retention Periodまでの任意の位置に秒単位で復元可能

障害テスト

  • SQLによりノード・ディスク・ネットワーク障害をシミュレーション可能
    • 擬似的に、障害をシミュレートできる

パフォーマンスを引き出すために

  • クエリ並列度は高い、データサイズが大きいケースで高価を発揮
  • ロック機構や暮れ裏キャッシュに手を入れて性能向上を行っている
    • write heavyな環境ではoffがおすすめ
    • CPUを効率的に利用する改善を入れているので、CPU使用率がMySQLと比較して高くなるが、性能は落ちにくくなっている
  • 性能は最大5倍
    • re:Inventで発表されたものは、4インスタンスからr3.8xlargeにSysbenchを並列実行したケース
  • TPC-Cをr3.8xlargeに実行した場合は、2.5倍の性能を計測

マイグレーション

  • RDSからのマイグレーションは、クリック1つ
  • MyISAMに対応していない
  • MyISAMが含まれている場合は、コンバートが発生するためにディスク容量が必要
  • MySQLからレプリケーション可能
    • Auroraからのレプリケーションはサポートしない

使いどころ

  • クエリ同時実行数やテーブルサイズが大きいケース
  • 複数のサーバにシャーディングをしている
    • 障害時の影響は考慮


まとめ



オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)