by shigemk2

当面は技術的なことしか書かない

memo 2000万アカウントの無停止データ移行の裏側 #datamigrationnight

AWS

アジェンダ

  1. ゴール
  2. 課題
  3. 新旧同期Replicatorとは
  4. 新旧同期Replicator移行の流れ

ゴール

新環境旧環境で同期させる

課題

  • データ構造が異なるDBへ移行する
    • 全然違うデータ構造だった
  • 停止は避けたい
    • いろんなメンテが走っているから

  • 切り替えタイミングを任意としたい

    • 各プロジェクトが最適なタイミングで

  • プラットフォームの見せ所

実現に何が必要か

機能要件

  • 双方向レプリ
  • スキーマのマッピング
  • リレーログの永続性

非機能要件

  • 低レイテンシー

設計

  • 2つのマスターがあって、レプリケーターが2つ
  • RabbitMQのキューを配置(binlogの永続化)

  • マッピング情報はymlで

    • いろいろできるyml
    • insert/update
    • green

  • mysql replicator

  • rabitmq adapter
  • query mapper

  • query executor

  • SQL Parser/Source Query/Destination Query

  • 性能実績 4000req/secが限界
    • 更新クエリ99%を15msで同期

同期の流れ

  • 同期できる状態で新APIの提供
    • 1処理で大量のcommitする場合はズレに注意する事
      • 最終的に整合性あえばよい
    • 循環同期
      • 更新者を明示してクエリの更新を止め、循環しないようにする
  • データの矛盾確認
    • マッピングに従って同期するだけ
    • データに矛盾がないか分からない
    • codeception(PHP)でテストを生成
  • vert.x

memo オンプレからAWS移行で変えた3つの意識 #datamigrationnight

AWS

atnd.org

CyberZ

ターゲット

  • クラウド使ったことない人
  • AWS以外のクラウド環境を使ってる人
  • データマイグレーションを考えてる人

FOXとは

  • サードパーティトラッキングツール
    • アプリとユーザーをサーバーで繋いで効果を計測する
    • 7/24/365連続可用性

なぜクラウド環境を利用するのか

  • 流行
  • ランニングコストを最小限で始める
  • アプリケーション開発に集中

3つの意識

  1. コスト意識
  2. AWSオペレーション意識
  3. システムダウン意識

今回は事例を述べる

コスト形態

  • オンプレミス 資産(減価償却している)
  • クラウド 経費
    • 運用コストと機能追加の際の追加コストの把握が必要
  • コストレビューの実施
    • プロダクト単位じゃなくてtプロジェクお単位でのコストを算出する
      • コスト増加が想定通りか
      • 規模にあったコストになっているか
      • サーバーやDBを統合するなどアプリの改修も含めてコストカットする

事例

  • キャパシティ不足
    • リザーブドインスタンス
      • 高割引な一括支払いによるコスト削減
      • キャパシティの確保
        • 対象AZでのインスタンスには在庫が存在するので、インスタンスが作れないという事案が発生する
        • RIで予約するひつようがある

AWSオペレーション意識

  • アプリケーションエンジニア
    • アプリに関わる作業の専任

  • インフラエンジニア

    • インフラ専任
    • 撤廃
    • インフラ構築や監視はアプリケーションエンジニアがやる

  • アプリケーションエンジニアに権限を移譲

  • インフラに関する知識の向上
    • 人に合わせて教育
  • オペミスが発生しない状況の作成
    • IAMでアクセスは制御

事例

  • 発展運用プロジェクト
    • AWSの新機能の調査
    • 運用効率化
    • 底上げサブプロジェクト
  • DynamicTag
    • アタッチしたEBSに同じタグを登録
  • DynamicDNS
    • インスタンス作成時にRoute53に自動登録

システムダウン意識

  • オンプレ
    • サーバーをダウンさせない
  • クラウド
    • サーバーがダウンしても復帰すること

方針

  1. マネージドサービスの積極的採用(EMR/RDS/Lambda)
  2. クリティカルな部分は最低限修正してEC2上で構築し移行

事例 RDS再起動

  • Required/Available
    • Requiredメンテナンスの場合は設定デフォルトだと自動アップデートがかかる
    • RDSにダウンタイム

まとめ

  • クラウド環境は新しいサービスがでる
  • 意識やアーキテクチャーを変えるのが クラウドの醍醐味

memo ChatWorkがデータマイグレーションに使った技術の話 #datamigrationnight

AWS

atnd.org

マイグレーションしたらsparkの処理速度が3倍になった

チャットワークとは

  • 説明不要
  • 国内最大手

データマイグレーション

  • システムマイグレーションに付随

    • メッセージングシステム部分の大刷新
    • 並列分散システム化
    • トランザクションに依存しない
    • HBase(RDBMS to NoSQL)
    • ScalaMatsuriでシステムマイグレーションのお話をした

  • アーキテクチャ

    • akka(spallowforwarder readAPI writeAPI updater)
    • kafka
    • HBase

  • 今回の話は、AuroraからHBaseへのマイグレーション

  • 17億メッセージデータ

  • 新たに「ルームで何番目の発言か」をフィールド上で算出(計算)

  • 工数書けない

  • Spark

    • MR
    • エキスパートの存在と安定性が理由でSparkをとった
    • SparkからHBaseへのバルクロードが可能
    • 大量データアップロードはバルクロード一択
  • EMR
    • Spark実行環境
    • 試験用環境
    • Auroraのバイナリログを読むためのmysql-binlog-connector-java
  • concourse
    • jenkinsみたいなもの

柔軟で安全なマイグレーションのために

戦略

  • 基本マイグレーション
    • 全件のマイグレーション
  • 差分マイグレーション
    • 前回以後の差分をマイグレーション

  • 基本 + 差分のコンボ

  • Spark

    • HBase-Sparkで書き込み
    • binlogからメッセージテーブルへ
      • 直接イベントとして取得する
  • 定期 or 手動でスナップショットをとる
  • 復元してマイグレーションと差分検証する。Productionへの負荷はない
  • Auroraのbinlogを使うときは復元するときにrotateする
  • rotate以外にも本番とその復元DBとでやりたいことに差がでないか検証する
  • EMRを使うと、スケールアップ/スケールアウトが簡単 札束で殴ればなんとかなる

安心安全なマイグレーションのために

  • メトリクスをしっかりとる
    • DBの急激な変化に気をつける
    • マイグレーションできてもDBの異常は検知する

Sparkアプリケーションの高速化

  • Sparkの仕様への理解
    • shuffleは高コストなので避ける
    • RDDのPartitionを意識する
      • Custom Partitioner
      • RDD#mapPartitionsメソッド
      • Partionerの保持
      • RDDでゴリゴリやるのが適してた

データの特性の把握

  • 基本マイグレーションPartition戦略最適化
    • データがどのノードにあるのかを意識する
    • ナイーブな実装 one Partition one Room
      • データのソートとカウントすればRoom単位の処理になる
      • 粒度が細かい→Auroraの読み込みスループットが上がらない
    • one partition n room
      • 複数のルームがはいる
      • roomIdでgroup byするとシャッフルが発生する→無駄
    • one partition n room
      • ソートとカウントしたあとで、データをregion単位でrepartitionする
      • HBaseContext.scala:791 repartitionAndSortWithinPartitions
      • 分散配置のルールに従って移動する必要がある
      • SparkのパーティショニングをHBaseと揃える
      • 1ノードにつき1RegionServer
      • 1 partitionあたり1 regionにするとshuffleするけど軽い
      • (RDDの型がPair型じゃないといけないので、Valueに適当なダミーを割り当てる必要がある)

  • 負荷の偏りをかいけつする

    • 基本マイグレーションの高速化はそれなりでよい
    • データ分布に基づくケアでバランスを取る

  • 事前パーティショニングが検証時に活躍

    • HBase/Auroraの突き合わせ
    • Aurora HBaseのデータが同じパーティションに配置されるようなCustomPartitionerを最適化

  • そのほかこまいこと

    • HBaseはpre-splitしていること
    • Region数が少ないとSparkクラスタサイズを大きく出来ない
    • ルーム分布のケースなので必ずしも汎用的じゃない

まとめ

  • Shuffleを減らす or 軽くする
    • Partitionの単位を工夫
    • Custom Partitionerの全体ロジックを検討

  • 各ワーカーの負荷を均等に

  • binlogによるストリーミングマイグレーションとかはやりたかった

トラブル

  • copyがタイムアウトでひたすらリトライ→権限付与で解決
  • HBaseのレアなバグ
    • 大きいデータを使うと踏む
    • 1.2.1で修正されていたバグ

Java EE8 and its latest topics memo #jjug_ccc

Java

Java EE8のはなし

まだ完全に決まってないので、変更の余地はある

現行Javaは、Java EE 7

Java EE 8について

なにをやろうとしているか 新しいAPIについて

JAX-RS 2.1

  • ractive client api(非同期 + リアクティブ)
  • server-sent events

  • hypermedia API enhancements

  • JAX-RS 2.0は

    • EE 7については、クライアントサイドの実装があった
    • ClientBuilder.newClinet()
    • 使いたいリクエストを構築する
    • 非同期機能はあった
    • 非同期メソッド

  • JAX-RS 2.1

    • RXをつかって最初のリクエスト
    • ２回めのリクエスト
    • 組みあわせが可能になる
    • Sync/Async/RXの3つのAPIが存在する
    • 全部OK
      • perfomance and scalability
      • easy to develop and maintain
      • complex workflow
      • error handling
      • leverage new Java SE feature
    • server-sent events
    • clinet server api
    • 新しいAPIがサーバー側クライアント側にも入る
      • SSE
      • payloadを送る
      • SseEventSource

  • JSON-P 1.1

  • JSON-B 1.0
    • JAXB-like API
  • JSON-B 1.0 Customizations
    • Jsonb APIはスタンダードなAPI
    • ソリューション上
  • Servlet 4.0
    • support http2
    • http2
      • binary framing(TCPのレイテンシーを抑える)
      • preserve http semantic(フィジカルコネクションのオープンな状況)
  • Servlet 4.0
    • server push
  • JSF 2.3
    • better CDI integration
    • way more thins are injectable
    • finally marking legacy managed beans as deprecated
  • CDI 2.0
  • bean validatoin 2.0
    • SE 8
    • support for new Date/Time API
    • constraints applied to collection elements
    • optional wrappers
    • repeatable annotations
    • introduce new constraints
      • notempty notblank
  • security api for java ee
    • よりシンプルにセキュリティまわりを使う
    • 認証メカニズム
    • 複雑なAPIだったのが課題
    • よりシンプルなAPIを目指す
    • jaspic
  • wrap up(まとめ)

memo 非機能要件とSprint Boot #jjug_ccc

ツイートメモ(途中から)

便利ライブラリがないと、自前実装に鳴るのでちょっとしんどい。

拡張モニタリング

AWS

docs.aws.amazon.com

CloudWatch は DB インスタンスのハイパーバイザーから CPU 使用率のメトリクスを収集し、拡張モニタリングはインスタンス上のエージェントからそのメトリクスを収集します。そのため、ハイパーバイザーレイヤーで少量の処理が実行されるため、測定値間に違いが見つかることがあります