エンジニアが開発に集中するために、手間がかからない仕組みが重要
窪野安彦氏がYahoo! JAPANに入社した2004年、コンピューターは現在よりもかなり高価で貴重だった。当時の開発エンジニアに求められた思想は「人が頑張って、できるだけ有効に使おう、コンピューターが働きやすいプログラムを書こう」というものだった。
しかし今は、ハードウェアの価格が大きく下がり、クラウドの普及によりリソースの柔軟な運用が可能となっている。開発面でもスクリプト言語が多くなり、ツールも格段に進化した。開発効率も大きく向上したはずだ。
しかし窪野氏は、「使う道具は変わったが、『コンピューターをなるべく効率よく動かす』思想は進化していない、もっと人が楽をしてもいい」と語る。
窪野氏はYahoo! JAPANのサービスで用いられている一般的なシステムでの事例を挙げる。情報の提供元から、Yahoo! JAPANのサーバーに対してデータが入稿されてくる。そのデータをバッチ処理で整形し、問題がなければそのままYahoo! JAPANのデータベースに登録する。さらにアクセス数などの関係でパフォーマンスが追いつかない場合は、データベースからキャッシュファイルを作成し、多くのサーバーにコピーを送る。
ここでの問題は、バッチ処理は自動実行するcronに仕込まれているため、cronにトラブルがあるとバッチ処理が止まってしまうことだ。また、キャッシュファイル作成工程でも、キャッシュファイルのコピーに失敗してしまう可能性を抱えている。
そこで窪野氏のチームは、「使う道具が新しくなっているのだし、もっと手間がかからないようにできないか？」と考えた。
導き出された手法は、cronをやめてMessage QueueingやFaaS（Function as a Service）にする、というものだ。これで夜間にバッチ処理が止まることがなくなる。さらにキャッシュファイルを使用せず、KVSを立てて対応した。
現場が抱えている課題は他にもある。例えば「バージョンアップやセキュリティ対応が多い」こと。Yahoo! JAPANは物理・仮想サーバーを10万台以上抱えており、その上お客さまのデータを預かっているため、脆弱性はこまめに対応する必要がある。
プロジェクトにおけるエンジニアの主な仕事はサービスの開発だが、並行してバージョンアップやセキュリティ対応も行う必要がある。エンジニアが少人数だと、多くのサーバーに対してパッチを当てる作業だけでも人的リソースが厳しくなる。また、作業量は安定せず、例えば突発的なセキュリティ対応などで増える可能性もある。だからと言って、プロモーションなどの兼ね合いもあるため、開発スケジュールを後ろ倒しにすることは現実的ではない。結果としてエンジニアにしわ寄せがきてしまい、機能追加や改修、新たなセキュリティ対応もできなくなる、悪循環に陥ってしまうのだ。
そこで窪野氏は、担当を分けることを考えた。例えばバージョンアップ・セキュリティ対応の専任者がいれば分業ができるので、プロジェクトのエンジニアは、本来やりたかった開発に集中できる。
しかし社内の全てのチームで、このような運用を行うことは難しい。Yahoo! JAPANには多種多様な100を超えるサービスがあり、対応すべき案件が一気に集中することもある。専任者が全チームのサポートを行うことが望ましいが、プラットフォームがそれぞれ異なるため現実的ではない。人的リソースをなるべく使うことなく、まとめて面倒を見る仕組みを考えているうちに、窪野氏は「社内PaaS」という答えにたどり着いた。
