コミュ障の僕に「なぜ僕の説明は伝わらないのか」を教えてくれた書籍『ソフトウェアシステムアーキテクチャ構築の原理 第2版』の内容が、ベンチマーク報告にも適用できそうなことに気づきました。
本に記載されているような観点にそって記載していくことで「漏れなく分かりやすい記載」になると考え、ベンチマークレポートのテンプレートを考えてみました。
テンプレート：
はじめに、検証概要
..
検証環境
（『ソフトウェアシステムアーキテクチャ構築の原理 第2版』における配置ビュー、情報ビュー、開発ビューのようなものを記載します）
リージョン、マシンスペック、構成
例：
-
Athena
- オレゴン
-
Redshift
- オレゴン
- dc2.large
- ノード数 (1ノード, 2ノード, 4ノード, ..)
-
Spark
- オレゴン
- c4.xlarge
- コアノード数 (1ノード, 2ノード, 4ノード, ..)、マスターノード数:1
データフォーマット
例： 検証では下記のようなフォーマットのログのダミーデータを使用。データサイズは1レコードあたり xx バイト。
{
"id": "0dbe3c-db77-5984-b5ba-c964ae7a",
"time": 1490123456789,
...
}
データのバリエーション
例：
- 入力データのサイズ（1時間分, 2時間分, 4時間分, ..）
- 入力データ形式: JSON, Parquet, CSV, ..
- 圧縮の有無: gz, snappy, ..
- sort key / dist keyの工夫
データのフロー、ライフサイクル
ベンチマーク対象のサービスがどのようにデータを取り扱うかを記載。
例：
-
Athenaを使う場合
- S3からJSON/Parquet/... のデータを読み込み、SELECT結果をS3に書き出す。
- 現在の出力はCSVのみのようで、自作ツールなどでParquetフォーマットへは変換が必要。
-
Redshiftを使う場合
- Spectrum層により、S3上のParquetファイル等を外部テーブルとして扱える。
- Spectrum層がS3からデータを読む場合は、事前にAthenaなどでテーブルを定義しておく必要がある（Hiveメタストアを共有）。
- JSONテキストファイルの読み込みはまだのようで、Spectrum経由で読めるようにParquet形式に変換するツールが必要。
- SELECT結果を保持する場合はRedshiftローカルのテーブルとして保持。
- 不要になったデータはUNLOADによりS3上にCSV/TSVで書き出し。
- Spectrum層により、S3上のParquetファイル等を外部テーブルとして扱える。
-
Sparkを使う場合
- S3から JSON/Parquet/.. のデータを読み込み、SELECT結果をメモリ上に保持。各種フォーマットでS3への書き出しも容易。
- JSONの読み込みやParquetへの変換、Parquetでの書き出し、JOIN等がすべてSparkのジョブとして定義できるため開発が容易。
内部動作の補足
（『ソフトウェアシステムアーキテクチャ構築の原理 第2版』の機能ビュー、並行性ビューなども絡めて記載）
補足があれば。
パフォーマンスとスケーラビリティの比較
レイテンシー測定
例： 下記クエリで検証。
SELECT .. ;
SELECT/JOIN/Aggregate処理をログのデータサイズを変えて測定。
10回の試行の中央値を記載。timeコマンドでコマンド実行開始から終了までを測定。
| データサイズ | 実行時間(1ノード) | 実行時間(nノード) |
|---|---|---|
| 1 時間分 | xx 秒 | yy 秒 |
| 2 時間分 | xx 秒 | yy 秒 |
| 4 時間分 | xx 秒 | yy 秒 |
可用性とレジリエンスの比較
各種サービスの可用性（ダウンタイム）、コールドからの起動やクラスタ作り直しにかかる時間について記載。
例：
- Athena
- フルマネージドのためダウンタイムなし、起動・環境再構築にかかる時間なし。
- Redshift
- 定期メンテあり。クラスターの作り直し時などはデータの再ロード（＋データ処理の再実行）など必要。
- Spark
- フルマネージドでなくマスターノードが単一障害点の懸念あり。ただクラスタ内部にはデータを持たないため作り直しは容易。
運用の観点で比較
障害復旧・アラート、データ量の増加等にどのような手順で対応するかを記載。
発展性の比較
要件変更に対してどのくらい柔軟か、SQLの豊富さ、海外対応しやすさ（通貨、時差など）など
例：
- Athenaはお手軽だがインタラクティブシェルでの分析用のイメージ
- Redshiftは複雑な分析が得意そうなイメージ
- Sparkはスキーマレスのままいろいろなデータをあつかいやすそう
セキュリティの比較
..
コストの比較
（『ソフトウェアシステムアーキテクチャ構築の原理 第2版』では取り扱ってないがクラウド時代のベンチマークでは必要そう）
例えば1ヶ月あたりいくらになるかを記載（どのサービスを何時間実行した場合の計算なのか）。
請求画面に表示された額で答え合わせすると安心。
Athena
例： データの読み込み課金のため、読み込み量が多くなると料金も上がる。