個人ブログは小規模サービス、はてなは大規模サービス、Googleは超大規模サービスと言える。ここでは『大規模サービス技術入門』を16回にわたって要約し、大規模サービスを開発・運用するために必要な技術についてまとめる。
要約
大規模サービスを開発・運用する技術者のための入門書。はてなが開催する学生向けのインターンシップにおける技術講義をベースに解説。内容は、OSや計算機の動作原理、DBの分散方法、実践的なアルゴリズムをシステムに組み込む実装、大規模データをさばく検索エンジンの仕組み、システム全体を見渡すためのインフラ設計の知識など多岐にわたる。
１ 著書の全体像
説明すること
- 大規模なWebサービスの開発とは？
- 大規模データを扱うにあたっての課題、扱うための基本的な考え方とコツ。例えばOSのキャッシュ（cache）の機構や大規模データ前提のDB運用方法
- アルゴリズムやデータ構造の選択の重要さ。大規模データを例に考える
- RDBMS（Relational DataBase Management System）で扱いきれなくなった規模のデータ処理の方法。例えば全文検索エンジンの作り方
- 大規模サービスになることを前提としたサーバ/インフラシステムの例と概論
第2回〜第5回は大規模データを扱うアプリケーション開発に必要となる知識編。第6回〜第10回はデータ圧縮技法やアルゴリズム、プログラミングなど実装編。第11回〜第15回ははてなのインフラの構成。
説明しないこと
- Webアプリケーション開発の基本的なハウツー。MVCフレームワークやORマッパの使い方など
- 各種ソフトウェアの使い方。Apache、MySQLの設定方法やコマンドなど
- PerlやC++のシンタックスや技法などプログラミング言語の解説、ノウハウ
- 基本的なアルゴリズムやデータ構造（例えばソート、探索、リスト、ハッシュなど）の細かな解説
２ 大規模なサービスと小規模なサービス
はてなのサービス規模（2009年8月）
- 登録ユーザ100万人以上、1,500万UU（ユニークユーザ）/月
- 数十億アクセス/月（画像などへのアクセスを除く）
- ピーク時の回線トラフィック量は430Mbps
- ハードウェア（サーバ）は500台以上
はてなは大規模、GoogleやFacebookは超大規模
はてなは各種インターネットのトラフィック調査などで、国内で上位20位以内に入るサイトである。サーバ台数では百台から数千台あたりが大規模サービスといえる。GoogleやFacebookなどはサーバ台数数百万台規模、扱うデータはテラバイト〜ペタバイト（petabytes）級という超大規模サービスといえる（「Googleを支える技術」４選 （２−１）分散システム—大規模化参照）。なお、国内ではモバイルサイトにも大規模〜超大規模のサイトが散見される。例えばGREEやモバゲータウンなどである。
小規模サービスと大規模サービスの違い
- スケーラビリティ確保、負荷分散の必要：スケールアウト（サーバの横展開）、ロードバランサの導入、データの同期、ネットワーク通信のレイテンシ（遅延時間）対策など
- 冗長性の確保：サーバが故障してもサービス継続できる構成。9.11時Yahoo!はCDNサービスのAkamaiにコンテンツをキャッシュさせてトラフィックを迂回させて障害から回復した
- 省力運用の必要：サーバ監視用のソフトウェアの使用、情報管理のためのツールの使用で自動化する
- 開発人数、開発方法の変化：開発の標準化。例えばプログラミング言語の統一、ライブラリやフレームワークの統一、コーディング規約、ソースコード管理のバージョン管理システムの活用など
大規模データ量への対処
いかにしてデータを小さく持つか、複数サーバに分散させるか、必要なデータを最小限の回数で読み取るかが本質的な課題になる。
計算機はディスク（ハードディスク、HDD）からデータをロードしメモリにストア、そのメモリにストアしたデータをCPUがフェッチ（fetch）して何らかの処理を行う。またメモリからフェッチされた命令はより高速なキャッシュメモリにキャッシュされる。このようにデータはディスク→メモリ→キャッシュメモリ→CPUといくつかの層を経由して処理されていく。この各層の間に非常に大きな速度差があるというのが近年の計算機の特徴である。この速度差を吸収するためにOSやミドルウェアなどのソフトウェアが活躍しているが、限界があるのである。
３ 成長し続けるサービスと大規模化の壁
Webサービスならではの難しさ
Webサービスが他のアプリケーションに比べて難しい原因は、サービスが成長し続けることにある。例えばブログサービスのように、不特定多数のユーザに向けて開放するサービスの場合、データだけでなくトラフィックも増えていく。同時にデータの読み出し回数や書き込み回数も増える。こういったサービスの成長に合わせてシステム拡張が必要になるのである。
はてなが成長するまで
- 従業員3名のベンチャー会社：2001年当初Q&Aサイトの人力検索はてな立ち上げ期、初期システムはPentium ⅢのPCが1台、回線はADSL回線だった。その後はてなアンテナやはてなダイアリーなどの新しいサービスで状況が変わってきた
- 試行錯誤のシステム規模拡張：オープンソースソフトウェアを活用。ルータはLinuxボックスで安価に構築、HTTPリクエストの振り分けはApacheのmod_rewriteで代用、DBの分散はMySQLのレプリケーション機能を使う
- データセンターへの移設、システムの刷新：小さなサーバルームからさくらインターネットのデータセンターへサーバ移設作業開始。I/O負荷が高いサーバはメモリ重視、CPU負荷が高いサーバはCPU重視など最適化実施。冗長化はLVS＋keepalivedというロードバランサ＋稼働監視のオープンソースソフトウェアを導入。OSの仮想化、独自のWebベースのサーバ情報管理システムを開発、アプリケーションの各種ロジックやDBのスキーマの見直しも実施
システムの成長戦略
ミニマムスタート、変化を見込んだ管理と設計が重要。
４ サービス開発の現場
はてなの技術チーム体制
- サービス開発部：はてなの各種サービスの実装を担当するチーム。日々のアプリケーション的な改善を担当する
- インフラ部：サーバ/インフラシステムの運用を担当するチーム。サーバの用意、データセンターの運用、負荷分散などを担当
はてなでのコミュニケーションの仕方
- はてなグループ：ブログとWikiを組み合わせたグループウェア。日々の業務レポートの報告に使用。エンジニアはブログに依頼内容を書いて担当者にトラックバックを飛ばす。メールは不使用。作業ログをブログやWikiにまとめたりする
- IRC：IRCチャットを使ってのコミュニケーションに利用。リアルタイムの情報を共有する
- サーバ管理ツール：エンジニア間のコミュニケーションツール。メンテナンス予定の有無、負荷状況の参照など
サービス開発の実際
- 毎朝各チームごとに10分程度の短いミーティングを行う
- タスクの担当者を決める
- 実装にあたってはなるべくテストを書く
- テストを書いたら実装。バージョン管理システムにコミット
- チーム内の他エンジニアへコードレビューを依頼
- プロダクション（実際に動いているシステム環境）のコードにマージを行い、ステージング環境（動作確認用の環境）で動作確認を行った後、プロダクションシステムに反映を行う
開発に使うツール
- プログラミング言語：Perl、C/C++、JavaScriptなど。標準化のため「同じレイヤの言語は1つに絞る」。C/C++は検索エンジンなどメモリ要件がシビアな際使用
- 主なミドルウェア：ミドルウェア/フレームワークも統一。Linux、Apache、MySQL、memcachedなど
- Webアプリケーションフレームワーク：自社開発のRidge。Perlのフレームワーク。O/RマッパにもDBIx::MoCoという自社開発のライブラリを使用
- 手元のマシンのOSやエディタ：基本的に自由。VMwareやcoLinuxのような仮想OSを各開発者が導入してLinuxを動かし開発を進める。エディタはEmacsかVim
- バージョン管理はgit、BTSは独自開発の「あしか」：BTS（Bug Tracking System、バグ追跡システム）は自社のgitレポジトリと連動した「あしか」という独自開発のWebアプリケーションを使用
- 開発ツールに関して：ツールではない部分の運用方法が本質的な課題
最後に
大規模なWebサービスの開発において生じる課題をまとめた。また、はてなの実際を紹介した。
次回は、メモリとディスク、Webアプリと負荷 大規模データ処理入門について解説する。
 |
[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB DB PRESS plusシリーズ) |
