前回、Googleの大規模システムのコスト削減の工夫について、主にハードウェアと電力の面からまとめた。最終回である今回は、グーグルにおけるシステムの開発体制について解説する。自主性、独自性、自動化の重視といった世界規模のWebシステムが作り出される原動力についても考える。
１ 自主性が重視されたソフトウェア開発
Googleには、エンジニアが主体的に行動することによってシステムをよりよくしていこうとする文化がある。
優れたプロジェクトだけが生き残る
Googleでは仕事は与えられるものではなく、自分で見つけ出すものである。開発者がマネージャーから一方的に仕事を割り振られることは基本的になく、数あるプロジェクトの中から自分に合ったものを受け持つか、あるいは自分から新しいプロジェクトを提案することになる。この開発者自身によるプロジェクトの自然淘汰が行われ、それに生き残ったものだけがGoogleのサービスとして私たちの前に提供されることになる。
少人数からなるプロジェクトチーム
Googleでは社内に大量のプロジェクトがある。1つのプロジェクトは2〜6人程度の少人数チームで構成される。開発拠点は世界中にあるため、各メンバーは主にメールやIM（Instant Messenger）、ビデオ会議やブログなどを通じて連絡を取り合っている。一方、オフィスは開発者2〜4人ごとの部屋に分かれており、ちょっとした会話は近くの同僚と気軽にできるようである。
各プロジェクトチームは、プロジェクトの立案から設計、コーディング、テスト、性能評価、デモの運用からドキュメントまですべてを行う。また、すべての開発者は担当プロジェクトとは別に、就業時間の20％を普段とは違う新しいことに費やすことも求められる（20％ルール）。さらに、インターンの学生にも様々な仕事をまかせることで、仕事の戦力として扱っていることがわかる。
コードレビューにより品質を高める
Googleでは、コードレビュー（Code Review）が必須とされている。何かプログラムを書いたら、必ずほかの開発者にもそれを読んでもらわなければならない。
コードレビューには2つの段階がある。１つはプロジェクトのオーナーによるレビューで、プログラムが論理的に正しいことをしているかどうかが確認される。もう１つはリーダビリティ（Readability、可読性）レビューといわれるもので、コーディングスタイル（Coding Style）が正しいかどうか確認される。
ソースコードの品質を保つことを持続するのは大変である。Googleでは開発者同士のレビューを通してこれを実現しているようである。
早い段階から性能について考えられる
Googleのソフトウェアでは、とにかく処理性能が重視される。コスト削減のためにも、すべてのシステムの動作を常にモニタリングし、その動作状況をグラフ化していつでも見られるようにしている。
単体としての速度だけでなく、スケーラビリティや信頼性、セキュリティも重視される。必要に応じていくらでも負荷分散したり上長化できるようにすることが設計の段階から考えられる。
新しいWebサービスが始まるまで
Googleで新しいWebサービスを立ち上げるには、以下のような一連のプロセスをたどる。
- アイデアを出す
- 基本設計を文書にする（背景・目的、設計、メンバー、セキュリティ・プライバシーなど、テスト・モニタプランなど）
- デモを作って意見を求める
- Google Labs、そしてBetaへ
情報は徹底して共有する
Googleでは開発者同士の情報共有が非常に重視されており、様々な機会や方法によって情報の共有が計られている。
- メーリングリストやブログ
- ドキュメントやデータベース
- TechTalk（社内プレゼン）
- TGIF（Thank God! It’s Friday!：自由参加の集会）
- レジュメ（履歴書）とスニペット（週報）
- 四半期報
２ 既存ソフトウェアも独自にカスタマイズ
Googleでは多くのソフトウェアを独自に開発しているが、既存のソフトウェアも大量に利用されている。
オペレーティングシステム
Googleのクラスタを構成する大量のサーバマシンには元々Red Hat Linuxが用いられていたが、もはや独自のOSの状態になっている。また、開発者が日常的に利用するOSとして、Ubuntuを独自にカスタマイズしたGoobuntuという社内向けディストリビューションがあるようである。
プログラミング言語
開発に用いるプログラミング言語は「C++」「Java」「Python」が3つの柱のようである。C++は各種の基盤システムや、インデックスサーバのように処理速度が求められるシステムで用いられる。Javaは様々なWebサービスの開発に用いられている。Pythonは主に社内向けツールの開発に使われている。これらに加えて、ブラウザ側で動作する必要のある「JavaScript」や、分散処理に用いられる「Sawzall」など、用途に合わせて様々な言語が組み合わされている。
一方、無秩序に利用言語が増えることのないように、使うことのできる言語は限定されている。例えば、Pythonに代えてRubyを利用することはできない。
データベース
大規模なデータの読み書きにはBigtableを用いるが、それ以外のところでは「MySQL」を利用している。
SCM（ソースコード構成管理）
SCMシステムにはオープンソースソフトウェアではなく、商用ソフトウェアの「Perforce」が用いられている。リポジトリは全世界に共有されているが、ソースコードを入れるにはレビューなどのプロセスを経なければならず、開発者が自由にブランチを作ることはできないようである。
レビューシステム
ソースコードのレビューには「Mondrian」という独自システムが作られている。Mondrianとは、BTS（Bug Tracking System、バグ管理システム）のTracのように、ブラウザ上でパッチの内容を確認しながら個々のパッチにコメントを付けたりできるシステムのようである。
３ テストは可能な限り自動化する
GoogleではWebサービスの開発者とは別に、ソフトウェアのテストを手がける専門のテストエンジニアも雇われており、テストの自動化に取り組んでいる。
プロジェクト横断的なチーム
Googleでは個々のプロジェクトチームとは別に、インターグープレット（Intergrouplet）というすべてのプロジェクトに共通するシステム（テストの自動化、国際化、セキュリティ、ビルドシステムなど）を開発するチームがある。ソフトウェアのテストには、開発者とは別に専門のテストエンジニアが雇われており、テストを自動化するための手助けをしている。
自動テストを想定した設計を行う
Google Testing Blogによると、テストの自動化を成功させるには次のようなことが必要であるとしている。
- システムの内部的な詳細と、外部的なインターフェースの両方を考慮に入れる
- 個々のインターフェース（UI含む）に対する大量の高速なテストを用意する
- 可能な限り低レベルにおいて機能の検証を行う
- エンドツーエンド（利用者からバックエンドまで）のテスト一式を用意する
- 開発と並行して自動化に向けた作業を始める
- 開発とテストとの間にある伝統的な垣根を打ち破る（例えば、空間的、組織的、プロセス上の壁）
- 開発チームと同じツールを使う
基盤システムをテストする
Googleにおけるテスト自動化の例として、Bigtableをどのようにテストしているかの紹介があるため載せる。
テストは大きくユニットテストとシステムテストに分けられる。ユニットテストは、テスト用のツールを使って個々の機能を独立して確認するもので、システムテストは実際と同じ環境でテストを行うものである。
ユニットテストの例としては、テスト対象のシステムから呼び出されるモックを作ることが挙げられる。あるいは逆に、テスト対象のシステムを外から呼び出すテストドライバを実装することもある。こうしたテストは、Bigtableに手を加えて実環境に導入される前には毎回実行される。
最後に
Googleでは開発に必要となる情報の共有が重視されており、それによって開発者は自主的にものを考え、よりよいソフトウェアを生み出していけるようになっている。また、テストの自動化に力が入れられており、そのために専門のエンジニアのチームが作られている。さらに、Googleではよりよいソフトウェアを作るために、エンジニア自身が積極的にシステム改善のための提案を行うよう推奨されている。
様々なシステムをより優れたものへと改善していこうとする、エンジニアのたゆまぬ取り組みによってGoogleという巨大システムは作り続けられている。
６回にわたって下記本の内容をまとめた。著者の西田圭介氏に感謝したい。
 |
