「絵で見てわかるシステムパフォーマンスの仕組み」を読んだ

絵で見てわかるシステムパフォーマンスの仕組み

目的、モチベーション

バックエンドのパフォーマンス改善において、指標となるCPUやメモリ等の基礎の理解を深め、実際の調査方法などが知りたかった。

全体の感想

表紙とタイトルから、図録みたいなものなのかと勝手に連想していたが、いい意味で裏切られた。普通にテキストによる説明がメインで、他の技術書よりもイメージをつかみやすいように絵がたくさんあったという印象。
アルゴリズムやデータ構造、アプリケーション、OS、インフラ、プロジェクトの進め方など、カバー範囲がとにかく広かった。
パフォーマンスのボトルネックの調査方法を知りたいのが目的の一つだったので、OSのコマンドの使い分けなどは特に良かった。
またパフォーマンステストの進め方は目的ではなかったが、私の経験で思ってるよりも時間がかかったり、再現が難しかったり今まであまりうまくいかなかったことが言語化されていて、整理もできて良かった。

少し個人的に残念なのは、2014年に出版された本のためDockerやコンテナ周りの話は触れられてなかった。

目次

概要

【第1章】パフォーマンスの基礎的な考え方

計算量やアルゴリズムの説明だった。知ってる内容だったので割愛。

【第2章】パフォーマンス分析の基本

2.2　必要なパフォーマンス情報とは

2.2.1　「はさみうち」の原則
前後の計測も行わないと、ただのスパイクなのか、何が原因なのかを確認できないので、必ず行うこと。

2.2.2　パフォーマンス情報の3種類

名前	特徴
サマリ形式	一定期間の合計や平均の情報。概況を抑えるのには向いているが、変動を捉えるのには不向き。
イベント記録形式	個々のイベントを逐次記録された情報。詳細な調査には向くが、データ量や負荷が大きくなるので、本番で常に実行するには不向き。
スナップショット形式	ある時点での状況の記録情報。定期的に取得することで、原因調査などが行える。

2.4　OSのコマンド

コマンド	形式	計測点	補足
sar	サマリ形式	OSのカーネルからのOS情報	CPU、I/O、メモリなどの概況がわかる。
vmstat	サマリ形式	OSのカーネル情報からのOS情報	実行待ちの平均プロセス数、ブロックされているプロセス数などがわかる。
ps	スナップショット形式	OSのカーネルで各プロセスの情報	プロセスの状態、CPU時間などがわかる。負荷が高いので高頻度で取得するには向いてない。
netstat	サマリ形式/スナップショット形式	ドライバレベル	ソケット、ルーティング、インターフェースごとの統計がわかる。
iostat	サマリ形式	OSカーネル内部のブロックデバイスレベル
top	スナップショット形式	OSレベル	OS全体の概況把握に最適。少々負荷が高い。
パケットダンプ（wireshark、tcpdumpなど）	イベント記録形式	ドライバレベル	負荷が大きく、パフォーマンスに影響が出る。
pstack	スナップショット形式	OSから見たコールスタックの情報	何度か取得し、詰まってる処理を特定して、アプリケーションなどの問題を特定する。負荷は低い。
システムコール（straceなど）	イベント記録形式	OSから見たプロセスのシステムコール情報	負荷が高い。
プロファイラ	サマリ形式	OSから見たプロセスの各関数の処理時間

【第3章】実システムのパフォーマンス分析

用語の説明が多かったので、割愛。

【第4章】パフォーマンスチューニング

4.3　現場で用いられるテクニック

パフォーマンス改善と一口に言っても様々な方法があるが、一覧化されると整理できて良かった。

• ループの省略、キャッチボールの削減
  • 局所最適に陥られないこと。例えば、DBで何度もINDEXを使った参照をするよりかは、1度のフルスキャンでデータを取得する。
• 参照頻度の高いデータはキーバリューストア化かハッシュ化する
  • ハッシュのアクセスはO(1)
• 参照頻度の高いデータは使う場所の近くに置く
  • CPUの内部レベルでも、CDNなどでも。
• 同期を非同期に変える
• 帯域制限
• LRU（Least Recent Used）方式
• 処理の分割またはロックの粒度の詳細化
• 不揮発なライトバックのキャッシュの採用
• マルチレイヤのキャッシュの採用
• ジャンボフレームと高速ネットワークの採用
  • パケットあたりのデータ量を増やすことでパケット数を減らし、CPU使用量を減らす
• 負荷分散、ラウンドロビン
• アフィニティ、バインド、Stickyセッション
  • キャッシュの特性を活かすために局所化する
• copy on write（COW）
• ジャーナル、ログ
  • DBへの書き込みなどを一括で行い、パフォーマンスを改善する
• 圧縮
• 楽観的ロック
• カラムナデータベース（Columnar Database）
• サーバのパフォーマンス設定は初期値＝最大値？

【第5章】パフォーマンステスト

この章では、パフォーマンステストの進め方が紹介されていた。
企画段階から、リリースしてから運用するまで、関係者とどのように進めるのかなど。
ややSIerっぽい内容ではあるが、環境構築や実際のテスト時の注意点は大変参考になった。

5.2　よくある失敗：9つのアンチパターン

5.2.1　期間内に終わらない！
本番環境でないと再現しない、再現するための環境構築に時間がかかる、特定の操作で問題発生などで、スケジュール通りに進まない。

5.2.2　パフォーマンスが出ない！　パフォーマンス問題が解決できない！
原因究明には、あらゆるレイヤーの知識が求められるため、時間がかかる。

5.2.3　環境差異を考慮しないために問題が発生
インフラやサーバの設定が異なるなど。

5.2.4　負荷シナリオ設計に不備があるために問題が発生

• 一部の画面操作しか考慮していなかった
• 長時間滞在して多くの画面を遷移し、セッションに蓄積されて多くのメモリが使用された

5.2.5　バッファ／キャッシュの利用を考慮しないために問題が発生
特定のデータやパターンを集中的にテストしたために、キャッシュが乗った状態で十分に検証できてなかった。

5.2.6　シンクタイムを考慮しないために問題が発生
本番環境でユーザが複数の操作する際にテスト時よりも時間がかかり、HTTPのコネクション数やセッションの維持数に影響が出てしまう。

5.2.9　テストに時間がかかる
インフラの環境構築、計測や監視の設定、負荷生成シナリオスクリプト、本番同等のデータ作成、調査の時間など。

5.3　パフォーマンステストの種類

開発段階に応じて、できる種類のテストが異なる（インフラ、アプリケーションなどの単体しか行えないなど）。
また、知りたいパフォーマンスの種類によっても分類できる。

• 狭義のパフォーマンステスト: 要件が満たせるか
• 限界パフォーマンス: 上限の調査
• 縮退パフォーマンス: 一部のノードが落ちてしまったときのテスト
• 障害テスト: 障害が起こってしまった際のエラーの確認や対応の確認など

5.4　プロジェクト工程で考えるパフォーマンステスト

5.4.1　要件定義
「スループット」、「レスポンスタイム」、「ユーザ多重度」の3つは必ず設定すること。これらは互いに依存し合うため、一つ改善しても他が悪化する可能性があるため。

【第6章】仮想化環境におけるパフォーマンス

仮想化をすることによって、CPUの命令の変換やメモリのマッピングなどの処理が入るため、遅くなる。
また、元のOSのCPU数より多くのCPUを使用するとオーバーヘッドが生じるので、チューニングが必要になる。

【第7章】クラウド環境におけるパフォーマンス

ざっと読んだが、今回の目的とは関係ないので割愛。

次のアクション

詳解 システム・パフォーマンスを読む。

絵で見てわかるシステムパフォーマンスの仕組み

「[試して理解]Linuxのしくみ」を読んだ

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

目的、モチベーション

バックエンドのパフォーマンス改善において、指標となるCPUやメモリ等の基礎の復習をしたかった。

全体の感想

サブタイトルにある通り、実験と図解を重視されており、理解しやすかった。
OS周りはとっつきにくく、今まで教科書的な本を読んだことがあったが、頭には入りにくかったりイメージしにくかったが、こちらの本は図がとにかく多いのが良かった。
あやふやだった点を整理することもでき、理解しやすく良書だったが、今回求めてたレベル感ではなかった。1,2年目のときに読みたかった。
OS周りの1冊目の入門書としてや、理解を整理したいときにオススメです。

気になったところ

第2章 ユーザモードで実現する機能

コマンド

コマンド	説明
strace	システムコールの呼び出しの詳細が見れる
sar	CPU時間の割合の詳細が見れる

第5章 メモリ管理

メモリに関する統計情報

統計情報の取得には、freeコマンドを用いる。

フェールド名	説明
total	全メモリの量
free	見かけ上の空きメモリ（詳しくはavailable）
buff/cache	バッファキャッシュ、及びページキャッシュが利用するメモリ。システムの空きメモリが減少してきたら、カーネルによって解放される。
available	実質的な空きメモリ。freeフィールドの値に、空きメモリがたりなくなってきたら、解放できるカーネル内メモリ領域のサイズを足したもの。

仮想記憶
プロセスが物理アドレスを直接扱うと、プロセス間で干渉したり、連続したアドレスが取得できない場合に処理が煩雑になってしまう。
この問題に解決するために、仮想記憶を介して、仮想アドレスを扱う。仮想記憶はページテーブルと呼ばれる、仮想アドレスと物理アドレスのマップングした対応情報をカーネルが使うメモリ内保存される。

デマンドページング
メモリはプロセスが生成された際に割り当てられる。これだとメモリが無駄に割り当てられる可能性がある。
デマンドページングを用いれば、仮想アドレスは最初に割り当てて、物理メモリは実際に使用される際に割り当てることで、改善できる。

第7章 ファイルシステム

ファイルシステムの不整合
システムの電源が処理途中に落ちてしまったりして、ファイルシステムのデータに不整合が生じる可能性がある。
不整合を防ぐ代表的なものは、「ジャーナリング」と「コピーオンライト」の2つの方式がある。

ジャーナリング
この手法では、下記のように処理内容を別のメタデータで保存することで防ぐ。

1. 処理に必要なアトミック処理の一覧を、いったんジャーナル領域に書き出す（この一覧をジャーナルログと呼ぶ）。
2. ジャーナル領域の内容に基づいて、実際にファイルシステムの内容を更新する。

1つ目の処理の途中で終わった場合はメタデータを破棄し、2つ目の処理の途中で終わった場合は再実行することで、不整合を解消できる。

コピーオンライト
この手法では、更新されるデータを別の場所にすべて書き込んでからリンクを張り替えることで防ぐ。
処理の途中で終わった場合は、再起動時にデータを削除することで、不整合を解消できる。

第8章 ストレージデバイス

HDDの性質上、ハードウェアがレイテンシーのボトルネックになる。
そのため、シーケンシャルにデータを配置し、できるだけ多くのデータを一度に取得することで、パフォーマンスの向上が期待できる。

I/Oスケジューラ

ブロックデバイスへのアクセス要求を一定期間溜めて、下記のような加工を行ってから、デバイスドライバにI/O要求をすることで、I/O性能の向上を目指す。

• マージ: 複数の連続するセクタへのI/O要求を1つにまとめる。
• ソート: 複数の不連続なセクタへのI/O要求をセクタ番号順に並び替える。

次のアクション

低レイヤーの理解が欠かせないなと思ったので、そちらの本とかを調査しつつ、もう1冊入門レベルの本（絵で見てわかるシステムパフォーマンスの仕組み）を買ったので読む。 あとは、積読中の詳解 システム・パフォーマンスを読む。

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

「Apache Kafka 分散メッセージングシステムの構築と活用」を読んだ

Apache Kafka 分散メッセージングシステムの構築と活用 (NEXT ONE)

目的、モチベーション

本業のプロダクトでKafkaを使っていて、理解を深めたいと思ったので読んだ。
読む前の状態としては、Kafkaは触れてるが大規模のデータを捌けるPub/Subメッセージを扱うログ型DBみたいなものぐらいのイメージだった。

全体の感想

生まれた歴史から、どのような仕組みで何を解決するものなのか、実際の例まで一通り網羅されていて、入門書として良かった。
実用例のパターンも何種類も紹介されていて、本番環境レベルではないがイメージを掴むには良かった。
インストール方法やコード例(Javaがほとんど)もあって、手も動かせる。
コードで動かさなかったが、半日ぐらいで読めた。

Kafkaは便利だと思っていたが、完全にメッセージを厳密に一度だけ処理するには、アプリケーション側でも冪等性を保つなどの工夫が必要で単純なものではないんだなと思った。

目次

概要

印象に残ったところを記載してます。少し公式ドキュメントを読んで補足している箇所もあります。

第1部　導入Apache Kafka

1　Apache Kafkaの概要

1.3　Kafka誕生の背景

元々は、LinkedInの下記のような技術的課題からオープンソースとして生まれた。

1. 高スループットでリアルタイムに処理したい
2. 任意のタイミングでデータを読み出したい
3. 各種プロダクトやシステムとの接続を用意にしたい
4. メッセージをロストしたくない

1.4　Kafkaによる要求仕様の実現

下記の3要素からなる。

• Producer: メッセージの送信元
• Broker: メッセージの収集/配信役
  • 挟むことで、ProducerとConsumerの接続先を一つにでき、増減などの構成変更に影響されないようにできる
• Consumer: メッセージの配信先

https://kafka.apache.org/images/producer_consumer.png

送達保証
Exactly Onceレベル(Consumerが処理を実行するのを一回にする)の送達保証をするために、トランザクションの概念を導入。

ProducerとBroker間では、BrokerがProducerにAckの返送に失敗した場合、ProducerがRetryしてBrokerがメッセージを受け取り、2度目以降は記録せずに排除することで実現する。
ConsumerとBroker間では、どこまでメッセージを受け取ったかのオフセットを管理されており、トランザクションでオフセットのコミットを行うことで実現する。オフセットコミットに失敗した場合、もう一度メッセージが処理されるため、Consumer側でも冪等性が必要。

2　Kafkaの基本

2.3　システム構成

Brokerは耐久性向上のために複数台で構成されており、ZooKeeperで分散処理の管理が行われている。

2.4　分散メッセージングのための仕組み

Partition: Topicに対する負荷を分散させるために、Partition単位で分割されている。負荷分散のために、Brokerクラスタ中に分散に配置される。

Messageの送受信
ProducerのMessage送信: メッセージがあるデータ量まで蓄積されたか、指定した時間毎に送ることでパフォーマンス向上できる。
ConsumerのMessage取得: 同様にまとめて送信することができる。

スループットの向上が期待できる一方で、レイテンシーが発生するのでトレードオフ。

Consumerのロールバック
ロールバックによって、メッセージのAt Least Once（最低でも一回は受信される）ことは保証できるが、Exactly Onceはアプリケーション側の対応が必要。

2.5　データの堅牢性を高めるレプリケーションの仕組み

ISR: In-Sync Replica, 最新の状態を保っているReplicaのこと。
最小のISR数を min.insync.replicaで指定できる。

High Watermark
レプリケーションが完了しているOffsetのことを指す。これより新しいOffsetのものはConsumerが取得できない。

ProducerのMessage到達保証レベルの調整
Messageが送信されたことを示すAckを、BrokerがProducerへ返す設定によって、性能と耐障害性に大きく影響する。

値	説明
0	BrokerのAckを待たない。Brokerに保存されたことは一切保証されず、リトライも行われない。
1	Leaderのレプリカに書き込まれたらAckを返す。Followerのレプリカに書き込まれる前に、Leaderが落ちるとデータロストが発生する。
all	すべてのISRの数までレプリケーションされたらAckを返す。但し、万一レプリケーションされてないノードのみ生き残った場合、データロストが発生する。

上記の「書き込まれた」というのはディスクに書き込まれたタイミングではなく、あくまでもメモリに書き込まれたタイミング。
ディスクへの書き込みは、 log.flush.interval.msを指定する。

3　Kafkaのインストール

インストール方法が紹介されてました。

4　KafkaのJava APIを用いたアプリケーションの作成

Javaの標準ライブラリでの実装例が紹介されてました。

4.4　作成したProducerアプリケーションのポイント

Producerの送信処理は非同期で行われるため、アプリケーション側で sendメソッドでメッセージをする際にはキューに入れられただけで実際の送信は別で行われる。

第2部　実践Apache Kafka

5　Kafkaのユースケース

下記のような実例の概要が紹介されてました。

• データハブ
• ログ収集
• Webアクティビティ分析
• IoT
• イベントソーシング

5.3　データハブ

システムが成長していくと、複数のDBやログデータを収集して分析用のDBなどに加工して送りたくなるケースが出てくる。
それぞれを直接つないでしまうと、影響範囲が広くなる上に、必要となるフォーマットが異なる度に実装が必要となってしまう。
このサイロ化の解決手段の一つが、データハブアーキテクチャ。上流のシステムの接続をKafkaなどのハブを介することで、疎結合にすることができる。

6　Kafkaを用いたデータパイプライン構築時の前提知識

6.3　データパイプラインで扱うデータ

ストリーミング処理では、複数のアプリケーションが常時起動している状態で、改修などで発生するデータの変更等を行わなければならない。

Messageのデータ型は、異なる言語でも使えるフォーマット(JSON, Apache Avroなど)を用いた上で、互換性を保つべき。
しかし、どうしても互換性を担保できないケースも出てくるが、Schema Registryを用いれば解決できるケースもある。
Schema Registryでは、Apache Avro前提で、Producerの送信時にスキーマ情報を保存してConsumerがそのスキーマ情報をもとにデシリアライズする。

7　KafkaとKafka Connectによるデータハブ

8　ストリーム処理の基本

9　Structured Streamingによるストリーム処理

5章で紹介されていたものの、実装例を中心に紹介されてました。

10　Kafkaで構成するIoTデータハブ

10.2　IoTに求められるシステム特性とKafka

IoTでは、下記のような特徴からKafkaと相性が良い。

• センサーデバイスはマシンパワーやストレージがない
• 大量のデバイスが接続されているため、データ量が多い
• 低レイテンシーが求められるケースが多い（すぐに反応しないデバイスは使いにくい）

10.3　センサーデータ向けデータハブの設計

センサー側でデータを加工するのは難しいため、サーバ側で加工することになる。
ブローカーに保存する前に、加工すればデータ量を削ることができるが、生データの情報が失われ、保存後に加工するとその逆が発生するので、トレードオフ。

軽量なMQTTプロトコルを用いれば、メッセージングモデルによる非同期処理が効率的に行える。

11　さらにKafkaを使いこなすために

11.2　Consumer Group

Consumer Groupというグループを各Consumerに設定することで、複数のConsumerで分散処理を行える。

各Partitionにつき必ず1つのConsumerが対応付けられるように割り当てられる。
そのため、Consumerの数が多いと割り当てられないConsumerが発生する。逆にPartition数の方が多いと、複数のPartitionが割り当てられるConsumerが発生する。
割り当てのロジックは partition.assignment.strategyで指定できる。

11.3　Offset Commit

enable.auto.commitでOffset Commitの自動化を切り替えられる。
現時点(2019/10/14)の最新のバージョンでは、基本的にはtrueがデフォルトとなっている。
自動化するとアプリケーション側の制御が不要になる一方で、障害のタイミング次第で複数回処理されたり、一度も処理されないケースが発生するので要注意。

11.5　Partition数の考慮

Brokerの数に対して、Partition数が少ないと送受信の処理の重いLeaderがあるBrokerに負荷が集中してしまうため、要注意。

Apache Kafka 分散メッセージングシステムの構築と活用 (NEXT ONE)

「RDBMS解剖学」を読んだ

RDBMS解剖学 よくわかるリレーショナルデータベースの仕組み (DB Magazine Selection)

目的、モチベーション

• DBの処理の一連の流れを俯瞰して理解したい
• 特に、実行計画やトランザクション管理など

全体の感想

SQLを解析して、どのようなプランでデータを制御し、トランザクションや排他制御、マルチバージョンをどのように行うかなどを俯瞰的に解説されてました。
SQL周りは特に目新しい情報もあまりありませんでしたが、特にトランザクションの制御やログなどはなかなか基礎的なところから説明した書籍等があまりないので、重宝しました。
廃版になってしまってるので手に入れにくいですが、DBの中の基礎知識がない方にはオススメです。

目次

概要

第1部　はじめに

全体の処理の種類や流れは以下の図のように整理できる。

Chapter 1　データベースの基礎とディスクアクセス

ディスクはメモリと比べて安価だが、数万とかのレベルで遅い。

第2部　SQLの処理

Chapter 2　SQLをどう料理するか（1）　SQLの構文解析

構文を解析して、構文ツリーを作成する。

Chapter 3　SQLをどう料理するか（2）　SQLから演算へ

論理プラン: SQLを操作手順に解釈して、代数の演算に変換し、どれが効率的に行えるか選択する
物理プラン: 論理プランをコンピュータ上の実行手順に書き換えたもの

Chapter 4　カタログとインデックス

カタログとは

• データベース情報
• テーブル情報
• ビュー情報
• カラム情報
• インデックス情報
• 制約情報
• データベースユーザ情報
• 統計情報(カラムの最大値、最小値、種類数など)
• ストアドプロシージャ/トリガー情報
• 性能情報

重要な用途は、「SQL構文解析の整合性チェック」と「最適プランの選択」。

Chapter 5　SQLの実行エンジン

テーブルスキャンやマージの種類が複数紹介されていた。
これらのアルゴリズムとカタログ情報から最適なプランを評価する。

Chapter 6　物理プランの生成

物理プランの最適化方式

有名なものは2種類ある。

ルールベース方式
事前に優先順位のルールを用意して、選択する。
テーブルの容量等が考慮されていないため、データの増減などの環境変化に対応できない。

コストベース方式
各統計情報から、「コスト」と呼ばれる最適化のための指標を算出して、最小なプランを選択する。

コストベース方式の例

第3部　システム化のサポート

Chapter 7　トランザクションの基礎

トランザクションをどのように保証するか

追記型では、古い値と新しい値を保持して、COMMITやROLLBACKの時点でどちらかを無効にする。
そのため、更新時には対象データの容量だけ余分にストレージが必要になる。

同時実行制御～複数のトランザクションが同時に実行される場合～

パフォーマンスを出すには平行して処理する必要がある。
一方でトランザクションが干渉しあうと、次のような問題が発生するので制御する必要がある。

• 更新の消失
• ダーティーリード
• 非再現リード

Chapter 8　トランザクション制御とMVCC

インデックスなどの内部ロック

Bツリーの場合はルートノードからリーフノードを探索するため、二相ロックに従うと一連のノードをロックしなければならない。
そのため、ツリープロトコルで実装されることが多い。

1. あるノードのロックを獲得
2. ロックを獲得しているノードの子ノードのロックだけ獲得できる
3. 個別のノードのロックはいつでも解放できる（ほかのトランザクションがロックできるようになる）
4. いったんロックを解放したら、このノードのロックは獲得できない

タイムスタンプを使った同時実行制御

ロック以外の方法の一つとしては、タイムスタンプをそれぞれのトランザクションに発行して、その順番を使って強制的に実行を制御することができる。
タイムスタンプの順番に従ってない場合はabortする。abortが連鎖することもあり、あまりよろしくない。

マルチバージョン同時実行制御

マルチバージョン同時実行制御(MVCC)は、タイムスタンプをベースとしている。
タイムスタンプでは、結果が正しくても実行順序に問題があると強制的にアボートされてよろしくない。
この問題に対して、古いデータを保持しておいて、トランザクションの一貫性を担保する。
データの書き込み中にも、古いデータを返すことで並列で処理を行える。

Chapter 9　ログ機能によるパフォーマンスの向上

データ更新処理の仕組み

ログファイルに書き込んだらcommitされる。
この時点では、データファイルにはまだ保存されていない。

ログ機能の構成と役割

パフォーマンス改善と、バックアップの2つの側面がある。

性能上の課題

ログの書き込みは、シーケンシャルなので、都度データファイルに書き込むよりもパフォーマンスがよい。

ディスクへの書き出しの性格の違い

バイナリログと実データのディスクを分離すると、ディスクヘッドのオーバヘッドが減り、パフォーマンス改善につながる。
複数のトランザクションを1度に書き込める可能性がある。

Chapter 10　ログによる障害からの復旧

データファイルへの書き込み記録であるチェックポイントをもとに、復旧時にREDOなどを行う

第4部　複数データベースをまとめる

Chapter 11　クラスタリングによる性能向上

Chapter 12　データベースのパーティショニング

パーティションを行うことで、各ノードでの全データアクセスのデータ量が減るので、パフォーマンスが上がる。
一方で、どのようにパーティションを行うか、どのレイヤーで制御するかなどの複雑性が上がるので、キャパシティプランニングが非常に重要。
また、パーティション間のデータを結合する際には余計にコストがかかる場合もあるので、設計も重要。

次のアクション

RDBMS解剖学 よくわかるリレーショナルデータベースの仕組み (DB Magazine Selection)

「NETFLIX コンテンツ帝国の野望 :GAFAを超える最強IT企業」を読んだ

NETFLIX コンテンツ帝国の野望 :GAFAを超える最強IT企業

目的、モチベーション

アメリカの大手テック系の中で、Netflixのことはビジネス的に全然知らなかったので、どういう歴史があり何が強みなのかを知りたかった。

全体の感想

ストリーミングに本格的に参入し始めた2011年までの話なので、もう少し最近の話を知りたかったです。
Netflixが古い会社だったのが意外でした。
基本的にはブロックバスターという競合との対比が多かったです。
社内政治はTwitter級にドロドロしてると感じました。

目次

概要

プロローグ

第1章 暗闇でドッキリ

1997〜1998年

DVDが普及しておらず、VHSからDVDに移行し始めてた時期に、DVDの宅配レンタル形式でスタート。

メンバーの1人は郵便局で3カ月働き、郵送のフローを把握して、いかにDVDの破損をなくすかを学ぶ。

サービスローンチ前は、狭いオフィスに泊まり込みをして体臭が漂い、他の会社の管理職級のメンバーが多く、人生を賭けた勝負という雰囲気。

サービスリリース直後は、テストに協力してくれてたインフルエンサーのお陰もあって、サーバが捌き切れないぐらいユーザ数と注文数がきた。サーバ増強の担当以外はDVD送付の対応に追われた。

第2章 続・夕陽のガンマン

1998〜1999年

DVDの規格化が進み順調だった一方で、レンタルは伸びずに、販売しか伸びてなかった。
共感力のないヘイスティングスが共同CEOとしてジョインして、社内のメンバーから反感を買いながらも、戦略的に物事が進むように。
レンタル事業に転換するために、Amazonと提携し、販売はAmazonに送客してAmazonでNetflixを宣伝してもらうように。

第3章 黄金狂時代

1999〜2000年

ヘイスティングスに経営権が渡ると、創業期のメンバーも徐々に退職して、社内の雰囲気も変わってく。

ブロックバスターに買収の話を持ちかけるも同意に至らず、真っ向から勝負することに。

第4章 宇宙戦争

2001〜2003年

ドットコムバブルが崩壊し、IPOが厳しくなったため、Netflixの価値を証明する必要が出た。
そのためには、大手レンタルのブロックバスターにとって脅威になる印象を与える必要があった。
そんな状況の中、ブロックバスターは店舗でのサブスクリプションサービスを開始し、Netflixの印象が変わった。
IPO前にはバーンレートが高く黒字化が厳しいため、4割の社員は一斉に解雇された。
無事IPOに成功し優秀で鋭い社員も増えた。家族的な雰囲気で経営する趣向があり、社内で権威を失いつつあった創業者のランドルフは退職することに。

第5章 レオン

2003〜2004年

Netflixは3桁成長を続けて絶好調だった。
ブロックバスターもオンラインを検討し始め、ビジネスプランを練ったがNetflixのクローンに行き着いた。
物流の基盤を整えるために、友人や親族に頼り、ネットフリックスの会員を装って物流センターを盗み見させたりもした。
Netflixは軽視して、値上げまでした。

第6章 お熱いのがお好き

2004〜2005年

ブロックバスターがオンラインに踏み出した。
別会社をつくって採用も別途行った。 社内では既存の実店舗の方が稼ぎ頭のため、カニバらないように実店舗より目立つ宣伝は行わないなどの制約はあった。 見た目はほぼ完璧にNetflixをコピーしたものをリリース。 しかし、システムの設計が悪く、エラーも噴出。

第7章 ウォール街

2004〜2005年

ブロックバスターのキーマンである、アンティオコスたちの話や、失敗に終わった同業他社の買収の話。

第8章 キック・アス

2004〜2005年

噂されていたAmazonの参入の対策を進める一方で、ブロックバスターは攻勢を強める。ブロックバスターは新規ユーザ獲得のため、赤字前提の値下げやスーパーボウルでCMを出すなどして、ユーザの獲得を順調に進める。

財務的にも長期的な継続は不可能だと見切り、特に対策を打たなかったことなども悪影響し、マスコミによるNetflixのネガティブな報道が増えた。

当時はSNSもなく、個人の発信はあまり影響力はなかったが、人気ブロガーは徐々に影響力をつけていた。

キューという在庫切れの作品を後で登録リストの機能では、定着しているヘビーユーザは後回しにして、新規ユーザを優先させるアルゴリズムになってる疑いがオンラインコミュニティ主導で騒動になった。

また、キューを家族のメンバーごとに区切れる機能や、自分のキューをシェアできるフレンズという機能をユーザに告知なくクローズして騒動になった。

第9章 我等の生涯の最良の年

2005〜2006年

ブロックバスターの実店舗の売上はどんどん落ちていき、閉店も相次いだ。その結果、オンラインでの値下げやキャンペーンの予算が大幅にカットされ、攻勢が終わった。更に、DVDを買うお金すらなく、あと払いを拒否された会社の最新作も十分な在庫を確保できなくなった。

Amazonはイギリス等ではDVDのオンラインレンタル事業を行なっていたが、国内では展開しないという話も流れた。

Netflixの株価は逆転して時価総額15億ドルをつけた。

第10章 帝国の逆襲

2006〜2007年

ブロックバスターは「延滞料金の終わり」キャンペーンで少し立て直して、オンラインのマーケティング予算を追加して、また値下げ合戦が始まった。

更に、実店舗で返却できたりするハイブリッドのサービスを提供し始めると、新規獲得ユーザ数はNetflixを上回り、本格的に潰しにかかった。

一方、Netflixはブランディングを強化して、論理的でない部分で、ユーザとの繋がりを強化した。 また、品揃えが少ないながらも、ストリーミング配信をスタートした。ストリーミングによって、どの部分で再生が終わったか、繰り返し見られてるかを計測できるようになり、より細かい分析が行えるようになった。

第11章 Mr. インクレディブル

2006〜2009年

シネマッチの精度を上げるために、アルゴリズムコンテストを開催した。膨大なデータの提供と賞金で多くの参加者を集めることに成功する。 AT&Tのチームが優勝した。 このアルゴリズムでは、会員が評価せずとも会員の行動のみで推薦でき、ストリーミングとも相性が良いものだった。

第12章 真昼の決闘

2007〜2008年

会員をブロックバスターに奪われ始め、打つ手なしになり、ブロックバスターオンラインの買収を提案するも、ブロックバスターに断られる。 ブロックバスターはCEOと株主の対立が深まり、CEOが退任することに。 Netflixは上場後初めて下方修正することに。ヘイスティングも疲弊し、社員も士気が低下していた。

第13章 大脱走

2007〜2009年

ブロックバスターの新CTOはセブンイレブン出身で小売業の人となった。デジタル音痴でオンラインでの成長よりもオフラインを重視する路線に。ブロックバスターの幹部達は次々に退職した。 ついには、倒産まで噂されるように。

思わぬ形でNetflixは救われ、ユーザの獲得も加速。 KUROというハードウェアをリリースして、テレビでデジタル配信のコンテンツを気軽に見れるように。売行きは好調で、波に乗って次々にコンテンツ提供会社と契約を結ぶ。

第14章 勇気ある追跡

2009〜2010年

第15章 ニュー・シネマ・パラダイス

2011年

海外進出に本格的に乗り出す。
一方でブロックバスターの二の舞にならまいと、ストリーミングに舵を切る方針に。
オンラインレンタルは別の会社にしてサービスも別々にするという徹底した方針や、リーマンショック後で不景気の中、オフラインレンタルを値上げしようとして、ユーザから大反発を買ってしまい大炎上する。
経営陣もブロックバスターを相手に闘っていたときに比べて、利己的になってしまう。

エピローグ

NETFLIX コンテンツ帝国の野望 :GAFAを超える最強IT企業