新しいWebサービスを開始する際や、既存サービスに変更を加える際に、サーバを何台確保するか、ストレージやAPIといった共有リソースを使用して良いか、ディレクターやアプリケーションエンジニアの方に訪ねられることがありますが（というかそれが仕事ですね）、その際相談のためにどんな情報を持って来て欲しいか書いてみます。人間同様にサーバやネットワークリソースも有限なので、無駄にならない最適なサーバ台数を割り出したり、増強が必要かどうかを判断して、会社のビジネスを効率よく進めていくことが重要です。
人によっては以下に書いてあることが、非常に緩く感じでしまうこともあるかもしれません。これはWebサービスを早く立ち上げて、柔軟に運用していくことができる環境ならではだと思います。それでも出して欲しいモノはいくつかあります
企画書
どんなサービスであるか説明できる企画書があるといいでしょう。ないわけはないと信じてます。既存のサービスの変更であればその変更分の資料になります。Power Pointや方眼紙Excelの立派な資料である必要はありません。1ページの図、wikiの1ページ、手書きでもかまいません。
オペレーションエンジニアはどんなサービスであるかの説明をうけ、どのようにサービスが実装されようとしているのか把握しようとします。実装がどのようになっているかは負荷やパフォーマンスの見積もりに重要な情報となります。
予測・目標PV、UU、登録者数
ほぼ企画書に含まれるであろう情報ですが、新しいサービス、機能にどの程度のアクセスがあるかの予測や目標です。誘導施策がありサービス開始直後のアクセスが多くなると考えられるならその予測と、2ヶ月3ヶ月経過した後の想定があるといいですね。PV予測は上の負荷・パフォーマンスの想定とあわせて、サーバ台数の見積もりに使います。数ヶ月先までの予想があるとサーバ購入のスケジュールが立てられるので、増強の必要が出た場合、スムーズに対応できそうです。
まったくの新規サービスで誘導も目立って行わない場合、PVの予測がないこともあるかもしれません。その際は最小の台数から開始になり、急激な負荷上昇があった場合でも対応するスピードは遅くなるかもしれません
蓄積するデータがある場合、その種類と量
Webサービスにおいて画像やブログ記事などコンテンツをユーザがアップロードする場合、データがサーバに蓄積されていくことになります。多くの場合、サーバに保存されるデータが一定の容量（メモリの容量）に収まっている間はアクセスが高速に行われますが、それを超えると劇的に遅くなります。大量のデータを保存する場合は値段の高い高速なディスクやメモリを多く積んだサーバを採用するか、データの分散ができるようアプリケーションを設計する必要が出てきます。またアップロードされたデータの冗長性を持たせる方法、バックアップについても考えなければなりません。ストレージは意外とコストに繋がります
貯めて行くデータがある場合、それが画像なのか、テキストデータなのかの種類と大体のファイルサイズ、また追加されていくペースが情報としてあると参考になります。
効果測定の方法
KPIの測定や経営陣への報告のため、アクセス数の集計やユーザの統計などを行うと思います。その際にあらかじめどのような測定が必要なのか相談をしておくといいでしょう。PV集計やデータ量の予測にも関係しますが、集計や統計を行う対象となるデータが大きくなればなるほどその作業に時間がかかるようになります。場合によってはサービスに影響がでてしまうほどです。
あらかじめ測定の項目について相談があれば、サービスに影響がでないように集計を行うにはどうしたらいいかを設計段階から考慮にいれることができます。
熱意
最後はネタに思われるかもしれないけど熱意。上にあげて来た項目が多少不足しても、そのサービスがどんなに面白いのか、ユーザがたくさん付くのかを説明する熱意が伝わると、運用する側としても独自に予測を行ったり、負荷が上ぶれても問題のない体制をとるモチベーションとなると思います。
会議に呼ばれても担当者がスマフォソをずっといじっていてサービスの説明すらないのは、協力とかそれ以前の問題です。会議の場では聞いてもないのに新しいサービスの「ほげほげがいいんですよ〜」と言ってくるぐらいのうざい熱意のほうがいい、、、、はず。
