AWSSummit-Day3.md

３日目

はじめに

• ✨…おすすめのセッション
• 🔥…難しかったセッション

基調講演

• 聞いてない

✨[12:00-12:40] B3-01 Amazon RDS for Oracle / SQL Server への移行ベストプラクティス✨

TL;DR

• オンプレ=>AWSへの移行の場合は、プラットフォームのみの変更(Replatform)と、DBエンジンも変更(Refactor)するパターンが考えられる。

  • 2年以内にサポートが切れるOracle 11.2や12.1、SQL Server 2008の場合は、Replatformを推奨

• 少しのダウンタイムが許容でき、同じDBエンジンに移行する場合、エンジンについている機能とかでほぼゼロダウンタイム移行が実現できる

  • SQL Server、Oracleでのリアルタイムデモを実演
    • ね、簡単でしょう？

詳細

既存DBを移行する際の悩み

1. たくさんのシステムが1つのDBを共有しており、密結合している
2. DBのダウンタイムを可能な限り短くしたい
3. 移行時のデータの漏れ/重複が許されない

考えられる移行パス

1. プラットフォームのみ変更(Replatform)
   • 例：Oracle => Amazon RDS for Oracle
2. エンジンもプラットフォームも変更(Refactor)
   • 例：Oracle => Aurora
3. プラットフォームを使った後にエンジンを変更する
   • 例：Oracle => Amazon RDS for Oracle => Aurora

• Replatformのメリデメリ

  • メリット
    • 移行しやすい
  • デメリット
    • ライセンスコストがかかる

• Refactorのメリデメリ

  • メリット
    • ライセンスコストがかからなくなる
  • デメリット
    • 移行コストがかかる

• サポート期限

  • SQL Server 2008のサポートは後１ヶ月
  • Oracle 11.2/12.1も２年以内にサポートが終わる
  • これらのものはReplatformを検討すべき

• 今回は１番目のReplatformにフォーカスをあてる

どのような手段で移行するか

• AWS Database Migration Service(DMS)

  • オンプレからAWSへの移行を行うツール
  • 最小限のダウンタイムで移行が可能

• AWSとしてはDMSを用意しているが、使い慣れたDB付属のダンプツールやレプリケーションなども利用可能

• 選択のフローチャート

  • 十分な停止時間を取れる？
    • YES
      • ソースとターゲットが同一DBエンジン？
        • YES => ダンプツール(シンプル)
        • NO => CSVアンロード(シンプル)
    • NO
      • ソースとターゲットが同一DBエンジン？
        • YES
          • 純正のレプリケーションが組める？ - YES => レプリケーション
            • NO => AWS DMS
        • NO => AWS DMS

• 今回は太字のものについて喋る

1. Oracleの場合

   • Oracle DataPumpを使用する方法

     1. expdpでDumpファイルを出力
     2. S3にコピー
     3. プロシージャーを実行してコピー

   • マテリアライズドビューを使用する場合

     1. RDS => オンプレに対してデータベースリンクを作成
     2. マテリアライズドビューを作成
     3. マテリアライズドビューログを作成
     4. マテリアライズドビューをリフレッシュ
     5. ワークロードを止める(ダウンタイムの発生)
     6. マテリアライズドビューを実表に変換する

   • マテリアライズドビューのデモ

     • 省略
     • 事前収録とかではなく、実際にリアルタイムでデモ、すごい
2. SQL Serverの場合
   • 十分なダウンタイムが取れる場合
     • .bakによる完全バックアップ
       1. .bakを出力
       2. S3のコピー
       3. AWSで用意されているプロシージャを実行
   • 十分なバックアップを取れない場合
     • レプリケーションを使用
       1. オンプレのSQLをパブリッシャーとする
       2. RDSをサブスクライバを
       3. レプリケーションを開始
       4. オンプレミスへの書き込み禁止
       5. データが書き込まれたことを確認したら、RDSに繋ぎかえる

• レプリケーションのデモ
  • 省略
  • 事前収録とかではなく、実際にリアルタイムでデモ、すごい(２回目)

まとめ

• 同一エンジン移行の場合、付属のツールや機能だけで移行できる
  • データベースリンク＋マテリアライズドビューとかを使えば、ほぼゼロダウンタイムで漏れ、重複なく、段階的に移行できる(アップグレードを伴いながら)
    • ニアゼロはおそらく1時間未満ぐらいに抑えられるか(所感)
    • ダウンタイムが必要なものはオンプレ=>RDSへのアプリの切り替えの部分、それ以外は全て起動しながら移行可能
• ウェビナーでオンデマンドでRDS各エンジンの特徴を学習できる(QR時間の表示が短い…)

✨[13:00-13:40] B3-02プロジェクトの実例に学ぶデータベースマイグレーションの課題と解決✨

　

TL;DR

• Oracle DatabaseからAurora PostgreSQLの移行案件を通して得た考慮事項の紹介と解決方法の共有
  • DB由来の考慮事項
    • NULLと空文字
    • DATE型の差異
  • Aurora由来の考慮事項
    • インスタンスモニタリング

詳細

• Oracle DtabaseからAurora PostgreSQLの移行案件を通して得た考慮事項の紹介と解決方法の共有を行いたい
  • 対象はAurora PostgreSQL 10系(9.6系も参考にできる)

Amazon Auroraの紹介

• 1/10のコストで商用DB相当のパフォーマンスと可用性を持つ、クラウド向けのMySQL/PostgreSQL互換のRDBMS

• AWS Schema Conversion Tool(SCT)

  • Fedora,Ubuntu,Windows,Macをサポート
  • データベースをモダナイズするGUIツール
    • データ移行機能
    • スキーマ変換機能
    • SQL変換機能
    • サマリーレポート
      • マイグレーションの難易度を把握できる

• Migration Playbook

  • 移行のためのベストプラクティスをまとめたホワイトペーパー

データベースエンジン由来の代表的考慮事項

• NULLと空文字

  • Oracle:空文字はNULL
  • PostgreSQL:空文字は0バイトの文字列
    • これらの差分を吸収するには、構文の空文字はNULLへ置き換える
  • 例：文字列連結演算子でNULLを連結する('test'||'')
    • Oracle:文字列が返ってくる
    • PostgreSQL:NULLが返ってくる
    • 文字列連結演算子を使わずにCONCAT_WS()を使用する
    • これらの差異もAWS SCTでサポート

• 一時表

  • Oracleでは一時表の削除にはDROP TABLEを使う必要があり、自動削除されない
  • PostgreSQLではトランザクションまたはセッションの終了時に一時表が自動削除される
    • 解決方法：CREATE TEMP TABLE IF NOT EXIST文を利用(あまり理解できていない)

• 日付/時刻

  • DATE型の違い
    • Oracle:秒まで
    • PostgreSQL:日まで
      • TIMESTAMP型に移行する
      • Oracleで時分秒を利用していないなら精査してDATEに変更することもOK
    • AWS SCTを使ってくれるとデフォルトでDATE＝＞TIMESTAMPに移行
  • DATEの演算
    • Oracle:(DATE-DATE) => NUMBER
    • PostgreSQL:TIMESTAMP - TIMESTAMPにして、EPOCHとかでNUMERICにキャスト
      • これもAWS SCTを使って可能
    • Oracle:DATEに数値リテラルを加減算
    • PostgreSQL:数値リテラルを期間リテラルに変換
      • これもAWS SCTを使って可能
    • TIMESTAMP同士のTIMESTAMP型の加減算
      • これらは互換性が高い型なので、そんなに問題はない
      • 期間リテラルの書式に違いにご注意

• パーティション

  • PostgreSQL10で宣言的パーティションタイプはRANGEとLISTのみ

    • OracleではHASHも利用できる

  • OracleでHASHパーティションを利用している場合、どのようなパーティションに移行するかを考える。

    • 主な目的であるパーティション間のデータ量均一化のために

  • パーティションの数は100以下を推奨

    • Oracleでコンポジットパーティションを利用している場合、200/300となる可能性がある
      • 性能試験を行なってね

  • パーティションのロック(PostgreSQL)

    • 子パーティションをDROPする際に強力なロックがかかってしまうので、DMLが待機となる、非機能要件を満たせるかを確認してほしい

Aurora PostgreSQL由来の代表的考慮事項

• インスタンスモニタリングとSQLチューニングを行うさい

  • 基本はPostgreSQL由来の統計情報ビュー
    • Auroraも由来の統計情報を持っている
      • pg_stat_activityビュー
        • SQL単位の特徴をモニタリング
      • pg_stat_statementビュー
        • 有効化してPoCや性能検証を行うことを推奨
  • Performance Insights
    • 待機イベントによるインスタンスモニタリング
    • TOP n SQLによりSQLワークロードモニタリング
      • 待機時間の長いSQLをモニタリングできる
    • これらを使ってチューニングすべきSQLに行き着くことができる
    • 七日間のパフォーマンス履歴保存、100万リクエス/月までの無料枠がある
  • SQLのチューニング
    • SQLがコピーできるので、Psqlからexplain analyze文を実行してチューニングできる

• いわゆるTemp落ちと一時領域

  • AuroraではDBの他に一時領域というものを確保している
  • Auroraが確保する一時領域(HDD/SSD)は固定
  • 一時領域はインスタンスタイプごとに違う
    • 一時表は一時領域に確保される
    • メモリがハッシュ結合、ソートが行えなくなると一時領域を使ってI/Oをしながら操作を行う(これがTemp落ち)
  • モニタリング方法はCloud WatchのAurora PostgreSQL -> モニタリングペイン->空きローカルストレージ
  • 不足したらどうしたらいいのか？ No Space left on Deviceというエラーメッセージが表示される
    • セッション数を絞ってワークロードをチューニング
    • 一時領域を使わないようにSQLチューニング
    • 予測される場合は大きなインスタンスに一時的に変更

• AWS SCTのTips

  • 利用している全データ肩を含む表を定義して、変換することで、デフォルトのデータ型のマッピングの全容を早期に確認する(なるほど！！)

🔥[16:00-16:40] A3-05 めざせ！サーバレスプロフェッショナル🔥

TL;DR

• サーバレスとAWS SAM
  • サーバレスとはサーバを考慮しなくていいサービス
  • AWS SAMはそれらのサービスを自動構成するサービス
• サーバレスを使うときに考慮すべきことは？
  • 開発フレームワーク
  • 複数環境、CI/CD
  • 再利用
  • 監視・モニタリング
• 難しかったのであんまり理解していない

サーバレスとは

• サーバの管理が不要になるという考え方
  • アイドル時のリソース確保が不要
• lambdaに言及することが多いが、様々なものが存在する
  • API Gateway
  • lambda

開発テスト・フレームワーク

• AWSCloud9、IntelliJ、Eclipse、Visual Studio

  • 使い慣れた開発環境に対してプラグインを提供しているので使える

• ワークロードを開発していくとAPI,lambdaサービスがどんどん増えていく

  • どのように管理すればいいのか
    • AWS Serverless Application Model(SAM)
      • AWSでサーバレスアプリケーションを表現するスタンダードモデル
  • SAMでYamlかJSONを書いてパッケージング、これがシステム構成になる(テンプレート)

• ローカル環境にSAMのテンプレートとソースコードを用意しておき

  • SAM => CLoud Formationテンプレート
  • ソースコード => S3でデプロイ

• テンプレート表記方法

Resorces:
  hogeFunciton:
    Type: AWS::Serverless::hogeFunciton (これはラムダを実行)
    Properties:
      Handle: index.handler(呼び出した際に実行されるもの)
      RUntime: nodejs8:10
      codeuri: s3:///....(実装コードの場所)
      Events:
        GetResource:  //API gatewayが追加される
          Ttpe: Api
          Properties:
            Path: /rescouce/{resourceID}(パスパラメータ)
            method: get
  
  hogeTable: //DynamoDB
    Type: AWS**Serverless::SimpleTable
    Properties:
      PrimaryKey:
        Name: id
        Type: String
      ProvisionedThroughPut:
        ReadCapacityUnits: 5
        WriteCapacityUnits: 3

• awslabsに公開リポジトリがあり、SAMのサンプルが提供されている�

  • 例えば、Express.jsのサンプルを動かすことができる
    1. git clone ...
    2. cd
    3. yamlファイルがあるので、
    4. npmでアカウントIDやリージョンする
    5. awsにデプロイする

• AWS SAM CLI

  • ローカルマシンでレスポンスやログの確認ができる
  • ラムダの実行環境をシミューレートしたDockerイメージが作れる
  • できること
    • sam init　--runtime nodejs8.10でサンプルプログラムが作れる
      • テストコード
      • アプリケーションコード
      • デプロイするだけでサーバレスが稼働できる
    • 関数ペイロード(???)の作成
    • 関数ペイロードを持ち手lambda関数をローカルで実行できる
    • APIをローカルで実行できる
      • sam local start-api(3000番ポート)

複数環境、CI/CD

• なぜ複数環境が必要？
  • リソースの重複を避ける
  • 新しいコード、インフラをテストしたい
• どうやって？
  1. アカウント戦略：AWSのアカウントを分ける
     • 同じアカウントをスタックを分ける(小規模)
       • 許可やアクセスの分類に難点
     • アカウントそのものを分ける(大規模)
       • アカウント管理が難しい
  2. 環境変数：固有の変数を利用する

     • ラムダ

       • Key:valueでできる

     • APIGateWayならばステージという機能

     • これらの環境変数をSAMを用いて１つのテンプレートから複数の環境を構築することができる

  • SAM：Infrastructure as Codeができる
  • CI/CD：テストとデプロイを自動化できる

開発ワークフロー

• Code兄弟(AWS CodeCommit,CodeBuild,CodeDeploy)と組み合わせて、CI/CDを実現できる
• パイプラインを作るために、CodeStarを使うのがおすすめ
  • テンプレートを作られるのでおすすめ
• 個別に設定したい場合は?
  • 段階的なデプロイメント
    • DeployementPreferenceを設定することで段階的にデプロイメントをおこなってkるえる
      • Canary10PercentXXMinutes
      • Linear10PercentXXMinutes
      • AllAtOnces
  • APIGateWayの機能であるCanaryリリース

再利用

• SAM,CloudFormationを使う
• AWS Serverless Apllication Repository
  • アプリケーション用のリポジトリ
  • Auto Publish
    • Pipelineから自動でパブリッシュを行なってくれる

監視、モニタリング

• CloudWatchと統合されている
  • 組み込みメトリクスが存在する
  • カスタムメトリクスも設定可能
  • ログも出力可能
• AWS X-Ray
  • アプリ内の調査に役立つ
    • リクエスト実行状況の確認
    • 様々なアプリに最適
  • トレースビューを取得できる
    • それぞれのサービスにおける時間とかトラフィックを測定えきる
  • サービスマップ
    • サービスを可視化することができる
      • それでもってサービスの呼び出しの結果を色で表現できる
        • これらから何が問題なのかを把握することができる

デザインパターン

• 汎用の場合
• 画像処理の場合
• データイベント処理の場合
• バックエンドデータ処理
  • それぞれ4つで合計１６個
• アーキテクチャ図が大量に出てきたので省略
  • 資料は公開されたときにまとめよう

[17:00-17:40] K3-06 Fate/Grand Orderにおける大規模なデータベース移行と負荷試験

• FGOに釣られた
• ディライトワークスの方

TL;DR

• FGOのレイテンシが低下してきたため、DBを垂直分割->水平分割へと移行
  • それに際して、徹底的に負荷試験を実施
    • ツール
    • シナリオ
    • リハーサル
• 泥臭い作業だが、地道にやっていくと成果が出る
  • 技術的な内容が多く楽しかった

アジェンダ

• AWS Database Mifrate Service(DMS)を用いたDB移行事例
• 移行後に想定トラフィクをさばけることを検証するための負荷試験手法

FGOについて

• APIサーバ：EC2

• DB：Aurora

• KVS：ElasiticAch

• サーバサイド：ASP.NET MVC4 Windows Server IIS

• クライアントサイド：Unity　C#

• FGOの特徴

  • DBのUPDATE/INSERTが多い
  • クライアントアプリもユーザの情報を持っている

DB移行の経緯

• 今回はDBのデータ量の増加が原因

  • メモリにインデックスが乗らなくなるとレイテンシーが劣化する

• サービスの影響のPhase

  1. 注目度の高いイベントの後に、APIサーバのレイテンシが上がる
  2. アクセスが多い時間にAPIサーバがレイテンシがあがる
  3. まともに遊べなくなる
     • 3までいくとやばい

• 想定外のユーザ数の増加により2018年1月にPhase１まで進行していた

  • ボックスガチャに影響が出ていた
    • レイテンシが10秒くらい

• DB分割とは

  • 垂直分割
    • テーブル単位の分割
    • 最大のインスタンスタイプ以上にスケールできない
    • 最大DB台数分のDBアクセスが発生する。
    • 部分的にコミットが失敗した場合の復旧が辛い
      • これらを加味して、水平分割に移行
  • 水平分割
    • GlobalDBとUserIDで割り振ったShardDB(??)

DB移行の詳細

• ユーザIDのキー(UserID%20)で

• AWS DMSを使用する

• ダブルライトを移行する

  • 参照するときは移行後のDBを、アップデートするのは移行前のものも

• AWS DBS

  • 最小のダウンタイムで移行ができる
  • DBSを動かすために、ソース、ターゲットとは別のサーバが必要
  • 注意点
    • Auroraのリードレプリカをソースにできない
      • Masterは怖いので、MySQLに複製したものをソースにしてい
      • ユーザIDをテーブルに持たす必要があった
        • ソースフィルタ機能が関数をサポートしていないため、
        • 十日間かけてゆっくりと

• スケジュール

  • 2018 3-7月
    • 7月の３周年イベントに間に合わせる

移行時の負荷試験

• 失敗リスクが高いため、徹底的に負荷試験をすることに

• 負荷試験の目的は以下

  • 本番ピークを捌けることを確認
  • ピーク以上のものも捌けることの確認
  • 移行リハーサルでの使用
  • 異常系の検証

• 負荷試験ツールに求めること

  • 気軽に負荷をスケールさせたい

• 負荷試験のシナリオに求めること

  • 手軽に再現したい
  • ユーザの挙動を再現したい

• 負荷試験の環境に求めること

  • 本番と全く同じ環境、ユーザの生データを使いたい

ツール

• master/一台
• minion/N台
  • portを枯渇しないように増やす
  • CPU、メモリを解消するためc5.x4largeに

シナリオ

• 本番で負荷が高かった時間帯のログからAPIを使用数をカウント

• 1つのプレイサイクルとなるAPIをまとめて「APIグループ」を作成

  • ログインとかクエストとか
  • 実行比率を調査

• 所有物が増えたまま「APIグループ」を終わらせないように調整

  • 「APIグループ」が無限に実行でいることを保証

• 実装中の一例

  • 過去のイベントを実行するとエラーになる
    • イベント日時が過去だから
    • masterを書き換えて対応
  • APが足りないとクエスト開始時にエラーとなる(無限にやりたい)
  • パーティに持ってないものを指定するとエラーになる
    • 負荷試験ツールにユーザの状態をキャッシュして、APが足りなくなったら回復を実行

環境

• 本番と全く同じ負荷試験環境を用意
  • CLIでスケールアップ、ダウンするスクリプトを用意
    • 落とすの忘れちゃうとお金かかるので簡単に落とせるように
• ユーザデータの絞り込み
  • 特定クエストをクリア
    • 「ある程度進めたユーザ」が欲しい
  • 休眠ユーザでないこと
    • 直近の新機能のデータが存在していない可能性があるので

AWSにおける注意点

• クラスタ数の緩和申請はお早めに
  • １週間くらい？(うろ覚え)
• かける側とかけられる側のAWSアカウントを別にする必要があります
• 負荷試験において1Gbpsを超えるのは事前に申請が必要

負荷試験

1. ２０１８年1月のピーク時と同じものが捌ける
   • 垂直環境で
     • レイテンシ上昇が発生することを確認
     • スループットが当時の同じことを確認　
       • ツールとシナリオが正しいことを保証
   • 水平環境で
     • 意外とすんなり捌けた
     • 確認観点が色々、メモできなかった
       • CPUが５０％、レイテンシが１００msとか
2. ２０１８年1月の２倍の負荷をかけた

   • 水平環境で

     • DBではなくなぜかAPIサーバのボトルネックが発覚した
     • RedisのCPU使用率が１００%に張り付いた
     • APIも70%、サーバを増やして対処
     • 複数のShardを参照するクエリが重い

   • 目標値を達成できなかったが、ピーク時の２倍でこれなら許容範囲と判断

移行リハーサルと段取り

• 当初(2h見込み)

  1. 移行後DBへFullLoad(コピーみたいなもの)
  2. 切り戻しDBへFullLoad
  3. CDC(Change Data Capture)を停止
  4. ゲームサーバをデプロイ

• 負荷をかけながら移行リハーサルを実施

• リハーサルの結果

  • 移行前＝＞移行後DBのCDCが追いつかない
  • 移行後＝＞切り戻しDBこれは問題なく追いついた
    • コミット数が少なかったから？
  • FullLoadは大丈夫

• 再考後(7h見込み)

  1. 移行後DBへFullLoad
  2. ゲームサーバをデプロイ
  3. 切り戻しDBへFullLoad
  4. CDCを停止

異常系試験

• QA担当が端末でプレイしながら用意されている障害注入クエリを入れる

• ダブルライト期間中、期間後で検証

  • 期間中に不整合が発生
    • XAを外した(??)
    • ダブルライト期間中は処理中断モードで乗り切る
  • 期間後は特に問題なし

• 移行リハーサルを丸一日やって問題なく終了した

  • 実際のスケジュールを見せてくれた、すげぇ

移行結果

• 3周年キャンペーン、アクセス数が７倍に増えたけど、レイテンシは特に変わらなかった
• ボックスガチャAPIのレイテンシが半分以下になった
• 元旦にアクセスしづらいことがあったが原因がわかったので、対策中

まとめ

• リリース前からスケール可能な構成を考えておくことが重要
• 色々な知識が必要で泥臭い作業だけでも地道にやれば成果が得られる
• 専任の負荷試験担当者が必要
• 本番想定の試験をしておけば問題なく動く