【勉強会メモ】Tech Deep Dive #2 in Osaka

techdeepdive.connpass.com

• 日時：2018/03/17(土) 13:30 〜 17:30
• 場所：日本オラクル株式会社　西日本支社　関西オフィス

オラクルさんが主催でWebアプリケーションの開発者向けに濃い話をするというテーマの勉強会でした。今回は性能の話が中心でした。

低レイテンシと高可用性

1つめの話はざっくり言うとクラウド時代の性能の考え方の話。Oracle Coherenceはインメモリ分散アーキテクチャによって高速アクセスと高可用性を実現している。

製品情報 - Oracle Coherence

自律型データベース・クラウド

2つめは昨年秋に発表されたOracle Autonomous Data Warehouse Cloudの話。アプリケーション側としてはデータストアやインフラのことは何も考えずに自動で監視・分析したうえでスケーリングや障害の検知・復旧をしてくれるのが理想だよねということで、既にそのような構想が進んでいます。

オラクル、世界初の自律型データベース・クラウドの構想を明らかに | Oracle 日本

近年はOSS中心の生活を送っている自分にとってはOracle製品の目指す世界観が先を行き過ぎていて圧倒される部分はありますが、クラウド時代の性能の考え方についてはおっしゃる通りで、効率よくスケールしたり整合性を維持して早期に障害検知して切り替え・復旧する仕組みはどういう製品や技術を採用するにしても考えなければならず、避けては通れない部分だと感じます。

Webアプリに低レイテンシ・高可用性を求めるのは間違っているのだろうか reloaded

いとうちひろ さん

Webアプリに低レイテンシ・高可用性を求めるのは間違っているのだろうか from Chihiro Ito

www.slideshare.net

今日の話のポイント

性能と可用性

性能が悪い製品はクラウド利用のコストが高くなる

性能でよく挙がる要素

• スループット
• レイテンシ

↓今後クラウドを使うと重要になる

• スケールアウト
  • スモールスタートで始めて負荷が上がった時にスケールアウトできないとツライ
• 効率性

可用性でよく挙がる要素

• Single Point Of Failure
• Disaster Recovery

↓今後

• 即時復旧
  • 止まると影響が大きいサービスも多い
• 整合性
  • 障害発生直前の状態に戻っていることが期待される

性能と可用性を意識したアーキテクチャの例

• リージョン内にゾーンが2つ
• AP Serverは2台で冗長化
  • Data Storeが止まると処理継続困難
• DData Store は1つStanby
  • 障害で切り替えに時間がかかる
  • 処理能力向上が困難

問題が起きると大変

• ログを収集
• 事象の確認
• 原因の調査
• 問題の修正

こんなアーキテクチャが欲しい

• とにかく速い
• 拡張できる
• 障害に強い
• 実装が簡単

↓

• リージョン複数
• スタンバイへの切り替えが速い
• AP Serverもスケールアウト可能

検証で行うデモの負荷パターン

テストケースA

• 1万件 の商品
• 徐々にユーザーが増加
• スケールアウト／アップの効果がある

テストケースB

• 1件 の商品（1件を取り合いになる）
• 徐々にユーザーが増加
• スケールアウト／アップが効かない

性能を意識したアーキテクチャ例

• Read Replicaによるオフロード
• キャッシュによる高速化
• シャーディング
• スケールアウト

方針

• 別ゾーンへ複製して冗長化
• 横に並べて冗長化

発生する問題

• リージョン障害でアクセス不能
• Read Replica⇒更新の反映遅延
• Cache⇒データ不正語
• Stanby⇒切り替え時間
• シャーディング⇒区分の変更が大変
• APサーバ増えた分のコネクション数増加

⇒リソースを使えない問題と使い切る問題

問題の分類

• 性能
  • 更新の性能限界
  • リソースを使い切る
  • リソースを使えない
  • 区分変更
• 可用性
  • 長い切り替え時間
  • データ不整合
  • 更新の反映遅延
  • ダメなコネクションを取得

リソースが使えないとは？

リソースが足りてないケース

• スレッドプールの枯渇
• オブジェクトプールの枯渇
• コネクションプールの枯渇

一人しか処理できないケース

• オブジェクトロック
• 行ロック

更新の性能限界に繋がる

テストケースA

• APサーバーは徐々に増
• DBのCPUが頭打ち

テストケースB

• ほとんどCPU使えていない

何を気にしないといけないのか？

• 負荷×インフラ×アプリ

負荷で気にすること

• 負荷全体に言えること
  • 今の負荷は将来の負荷ではない
• システム全体の負荷
  • 実際に起こり得る混合の負荷
• 特別な状況での負荷
  • キャンペーン時に単一商品への大量アクセス

インフラで気にすること

性能

• スケールアウト／イン
  • 増やすだけでなく減らすのも難しい
• スケールアップ／ダウン
  • アウト／インかアップ／ダウンか運用設計して考える
• スレッド、コネクション
  • スケールアウトは注意
  • クラウドだと気軽にスケールアウトできるけど1,2台ぐらいしか事前に試さないことも

可用性

• データストアの可用性
• 障害時の復旧時間
  • 絶対落ちる前提で普段から確認
  • 障害が起きた時しかわからない

インフラの性能で気にすること

スケールとリソース

• スケールアップしてリソースを増やす
  • リソース数を増やすのは限界があるので注意（CPU数やメモリ）
• スケールアウトしてリソースを増やす
  • 他のインスタンスのリソースを使い切ってしまう可能性があるので注意（コネクションなど）

インフラの可用性で気にすること

• アプリにインフラを極力意識させない
  • インフラの構成とアプリの設計を分離（疎結合）
  • アプリの問題なのかインフラの問題なのかの切り分け
• 全てのそうでSPOFを取り除く
  • 全ての役割のインスタンスを複数用意
  • リージョンをまたいだ環境の構築
• 高可用性構成の切り替え時間を短くする
  • 自動で検知
  • 自動で切り替え
  • 切り替えが短時間で完了

アプリケーションで気にすること

性能

• ロック
  • オブジェクトロック
  • 行ロック・表ロック
• スケールアウト
  • DataStoreがスケールアウトした際にアプリが持つ接続が再分散する

可用性

• スケールイン
  • 落ちた時に影響がないように

ロック時間が長い

• 処理を減らす
• CPUを早くする
• 無駄な時間を極力短くする

スケールでは対応できないので注意

アプリケーションの可用性で気にすること

スケールイン

• フレームワークで対応が必要

ロックについて

• ロックしないとどうなるか？
  • 在庫数よりも多くのものが売れてしまう
  • ホテルで部屋数以上の予約が入る
• ロック開放待ち中のスレッドは何も処理しない
• DataStoreが低レイテンシーなら性能が上がる

Cache

Cacheを使えばできるんじゃない？

テストケースA

• APサーバーがCPU使えるようになった
• CacheのCPU⇒DBのときと同じようにはCPU頭打ち
• スループット7.8倍

テストケースB

• Cache⇒CPUを使えていない
• DBとあまり変わっていない

結果

• Cacheは条件が揃わないとあまり早くならない
• ロック期間は変わっていない
• テストケースAは早くなる
• ECサイトなら参照系だけなら早くなる

In-place処理

テストケースBを早くするにはどうしたら良いのか

• データを取るのが遅い
• データのある場所で処理しよう

これまでの処理とIn-place処理

• APサーバで処理⇒データがある場所で処理する
• 5往復が2往復で済む⇒通信が早くなる

Entry-Processorを使うと通信をまたがない

インフラはどうしよう？

• 高速
• リソースをきちんと使い切る
• スケールアウトできる
• SPOFがなく自律的
• データストア内で整合性
• リージョンレベルで冗長化
• アプリは上記を意識死にで良い

インフラとして望む要件

• ロック期間が短くて済む
• 足した分だけスループットが増える（スケールアウト）
• ブロック処理がない（リソースを使い切る）
• ノードが落ちても気にしないで勝手に復旧（SPOF）
• データストア間での整合性を担保
• リージョンレベルで冗長化
• アプリはインターフェースを実装するだけで良い

こんなアーキテクチャが欲しい

• とにかく速い
• 拡張できる
• 障害に強い

• 実装が簡単

• APサーバ…アプリの実装が楽

• Cache…ブロック数が少ない
• DataStore…永続化と整合
• リージョン…別リージョンで冗長化

In-Memory Data Grid

• Coherence…OracleのIn-Memory Data Grid
• 様々なOracle製品に統合

Cohorence

• 標準に準拠
  • JCache
  • Lambda式
  • 他言語にも対応
• 処理が速い
  • In-Place処理
  • CacheStore
  • 分散
• 高可用性
  • 冗長化
  • Eviction…アクセス頻度が高いものだけキャッシュ
  • Federation
  • Persistence

テスト

• In-place版テストケースA
  • Cache版と同じ傾向のCPU使用率
  • スループット13.6倍
• In-place版テストケースB
  • APサーバのCPUを使えた
  • CoherenceコンテナもCPUを使えた
  • スループット31倍

まとめ

テストケースA

• データストアは常にCPUを使えていたが処理効率の違いからスループットに違いがある
• APサーバはレイテンシが短いとたくさん処理できてCPUをたくさん使う

テストケースB

• ロック時間が影響
• In-place版はロック時間に通信を含まないのでCPU時間だけのロックで済む

まとめ

• In-place処理で低レイテンシが実現
• In-Memory Data Gridは性能・可用性でメリットがいっぱいある
  • 高可用性（ゾーンレベル、リージョンレベル）
  • 必要なCPU数削減

もしもみなみんがアプリケーション開発者だったら

みなみん さん

システムによくある問題

• インフラを使い切れないアプリ
• 性能限界

• 可用性の問題

• 運用が大変で開発に注力できない

• 問題を分析・改善できない

性能を意識したよくあるアーキテクチャ例

• Read Replicaによるオフロード
• キャッシュによる高速化
• シャーディング スケールアウト

可用性を意識したよくあるアーキテクチャ例

• 横に並べて冗長化
• 別リージョンへ複製して冗長化

性能と可用性を意識したアーキテクチャの具体例

• Read Replicaを並べる
• シャーディングも可能
• Stanbyでデータ同期

よくある問題の例

• 書き込みと参照を分ける⇒書き込みが遅い
• Read Replicaを増やしても参照が遅い
• APサーバからの制御が難しい
• Stanbyの仕組みを作るのが大変

こんなアーキテクチャ

• Read Replicaのチューニング案を提示
• スケールアウトが簡単
• Stanbyの構築も簡単
• 接続先を意識させない

何を気にしないといけないのか？

• 性能と可用性

インフラの性能で気にすること⇒スケールとリソース

• スケールアップでリソースを増やす
• リソース数を増やすのは限界がある
• スケールアウトしてリソースを増やす
• 他のリソースを使い切ってしまう可能性

可用性で気にすること

• アプリにインフラを極力意識させない
• 高可用性構成の切り替え時間を短くする
• オペレーションミスのリカバリ
  • ミスのレベルに合わせたリカバリ手順

アプリケーションで気にすること

• パラレル処理
  • 他の処理に影響を及ぼさない適切な並列度
  • データ配置や処理性を意識した分散
• スケールアウト

オペレーションミス

よくある解決方法

• DataStoreを停止してバックアップからリカバリ
• スタンバイへ切り替え

実際には

• バックアップから戻すには時間がかかる
• バックアップが使えない
• スタンバイが使えない
• バックアップやスタンバイが元々無い

理想的な解決方法

• ミスごとの適切なリカバリ方法
  • トランザクション単位
  • テーブル単位
  • DataStore単位
• 簡単に取得できてきちんと戻せる
• 簡単に構築できて切り替え後にきちんと使えるスタンバイ

更新系の性能

よくある解決方法

• Read Replica⇒参照処理をオフロード
• シャーディング
• インスタンスサイズのスケールアップ

スケールアウト

• スケールアウトしたノードに処理が分散しない
• 特定のノードに偏る
• コネクションが残る
• キャッシュしない

理想的な解決方法

• あるユーザーは毎回同じDBインスタンスへ
• インスタンスの負荷をみて分散
• インスタンス停止を検知してコネクションを無効化
• インスタンスが停止してもAPにエラーを返さずに継続処理
• 停止したインスタンスのコネクションを新規リクエストに渡さない

性能問題

• コストがかかる
• 単純なHW増強では解決しない
• チューニングを試せない、環境がない

ベターな解決策

• 自動的に分析に必要な情報収集
• 問題の特定
• 改善案の決定／適用
• 自動性能テストの実施

ベストな解決策

• システムが改善案を提示
• 本番データを使って自動テスト

⇒簡単、高効率、高性能なシステム

オペレーションミス対策

• Flashback tecnologies
  • 特定時点に戻すことができる
  • DB全体のリストアが不要
  • 過去データを参照可能
• Recovery Manager
  • バックアップを利用した復旧
  • オンラインでブロック単位でのリストア
• Data Guard
  • リアルタイム・データベース複製
  • 自動検知・自動切り替え機能

更新系

• Real Application Clusters
  • サーバ数を増やしてスケールアウト
• Sharding
  • 複数のデータベースに分散配置
• Active Data Gurard
• GoldenGate
  • レプリケーション

スケールアウト

• Active GridLink for RAC
  • RAC側から状態を通知
• ランタイム接続・ロード・バランシング
  • RACの負荷状況判断
    • WebSessyon ・アフィニティ
• Single Client Access Name
  • 接続リクエストのリダイレクト
• データベース・サービス
• Automatic Storage Management
  • ストレージの分散配置・再配置の自動化

可用性

• Active GridLink for RAC
  • RAC側からの通知・連携
• Fast Connection Failover
  • コネクションプールとの連携
• Application Continuity
  • フェイルオーバーを透過的に実行

性能問題

• Compression
  • データ圧縮でI/O量削減
• Partitioning
  • パーティション化で処理量削減
• Parallel Query
  • パラレル化で複数CPUコアを利用
• Database In-Memory
  • インメモリ化
  • 列指向で演算処理を高速化

情報の取得・分析

• Diagnostics Pack
  • ボトルネックの把握
• Tuning Pack
  • パフォーマンス管理
• Real Application Testing
  • 性能問題を未然防止
• Enterprise Manager
  • GUIで管理・運用ツール

ここまで色々あげてきたものを使うのを考えるの大変

全部自動化できたらうれしい

自律型データベース

• Self-Drivision
• Self-Securing
• Self-Repairing

Autonomous Data Warehouse Cloud

• 自律型データベース・クラウド