はじめに─あるコンテンツプロバイダの悩み

はじめまして。 今回「使える！サーバ運用の実践テクニック」という題目での執筆依頼をいただきました。 まず，筆者が日々携わっているサイトですが，モバイル市場向けのCP（コンテンツプロバイダ）として，そこそこ大きなファイルのダウンロードサービスを提供しています。システム的にはよくあるSNSやゲームコンテンツなどとは違った（と思われる）以下のような悩みを抱え，日々仕事をしています。

月額利用料を持たないため，商品購入のつど，課金処理を実施する。

これは，月額，広告収入などの収益モデルではなく，ECサイトのような収益形態を取った場合，サイト停止によって機会損失額に対するインパクトが大きい事を意味します。

対象ファイルは10Mバイトを超えるようなものがある。

このため，ダウンロードが終了するまでWebサーバ側にセッションが残ってしまう点などへの考慮が必要になります。 モバイル（携帯電話）向けサービスの場合，少量のパケットで大量に通信される事と，PC等と比べて基本処理性能が劣る携帯電話の場合，どうしても長時間通信になる傾向があり，結果として「ダウンロード処理時間が長くなる＝長時間セッションを保持する」ことになります。

ピーク時予測が難しい。

たとえば扱うファイル（商品）が音楽であった場合，TV番組などで紹介された瞬間に予想するピークを遥かに超えるアクセスが発生したりします。

他にもいろいろと細かい事を気にしながらシステム構築を考えていかなければならないのですが，何となく「あぁ大変なんだな」と思っていただければ幸いです。

システム採用は「良いもの」が選ばれる？！─「良いもの」ってなんだろう？

筆者はIT業界，技術者である前に，まず事業を展開する会社の社員です。

事業を展開するユーザ企業が現場で採用する構成としては，必ず「良いもの」が選ばれます。ただし，「⁠良いもの」という言葉の定義が，一般的な技術者が考えるものと大きく異なる場合があり，また，ユーザ企業ごとに「良いもの」の定義も異なります。

機能だけで選ぶのであれば，オープンソースなどでも十分に提案，採用に向けたアプローチを行う価値があります。逆に，運用，保守，ハードやOSなどの組み合わせ，絶対に止められないミッションクリティカルなシステムに関する要件など，ユーザ側が求める安心をインフラ，ハード，その他機能などで代用できない場合，機能的にどんなに優れていてたとしても採用することはできません。

とくに日本の場合は，この辺りの「ユーザが求める安心」が高く，「⁠優位比較，機能網羅，コスト削減」のみを提案する技術者が多いような気がします。この場合，両者の間に溝が発生し，それが解決できなければ最終的にはその中間を別のミドルウェアベンダー製品などを導入するなどして解決する事も多いかと思います。

これをQCDの関係で表すとわかりやすいかもしれません。

ユーザは，まず「Cost」と「Quality」の関係を定義付け，それを「Delivery」実現できるかどうかで判断するでしょう。

新型ハードウェアを採用すればインフラが集約でき，運用的な「Cost」が削減できるかもしれません。そのためには，一時的な投資「Cost」がどの程度発生するか？ 要求する「Quality」を叶えるべく，「⁠Delivery」との関係から損益分岐を割り出して採用するか否かを決定します。

また，オープンソースを採用した場合「Cost」「⁠Quality」「⁠Delivery」全体が低下する可能性がある代わりに，先述したように技術者の確保などに関する体制の確立に「決断」と「固定費」が発生します。

ポイントとしては，いかに全体を見渡して適切な提案が行えるか？ それが実践できれば「良いもの」となるかも知れません。

止められないシステムをどう作り，育てるか

筆者は事業を展開する会社の社員ではありますが，その一方で，IT業界に身を置く技術者として，常に最新技術動向に関心を寄せたり，最小構成，高パフォーマンスを追い求めてチューニングに没頭したり，技術的分野で第一線で活躍したい！という矛盾ある目標も持って日々仕事に従事しています。

しかしながら昨今では，アプリケーションロジックやDBへのSQLクエリ，ミドルウェアのチューニングに工数を割り当るくらいなら，IAサーバ数台を投入した方が結果的に安価で性能担保を実現できる時代になった部分もあります。とくにLAMPなどで開発している場合，調達から構築，本番投入までの期間が非常に短くなり，そういった面では本当に良い時代になりました。

システムライフサイクルが本来持つべく意味や機能に関しては専門サイトや書籍にも記載されていると思いますので，ここでは一般的な考慮事項に加え，ちょっと変わった切り口で，ユーザ企業が抱える（実践的な）考慮点と，ポリシーをどう考えるべきかという点について記載します。

技術力だけじゃ判断できない「本当のところ」

たとえば，高度な技術力は技術者からすれば非常に魅力的ではありますが，（⁠効果が伴っているとしても，）その会社独自の開発，実装，チューニング等のお作法があって，クセのある運用し続けている企業だったとしたら，いくつかの問題点が出てくると思います。

まず，働く技術者のスキルパスですが，会社としては，事業の拡張等を念頭に活躍の場を広げ，専門職（技術系スペシャリスト）や，管理職（マネジメント）を目指してほしいと願います。そのためのリソースの確保等を行うべく採用を行ったり，開発時には業務委託等で対応する場合もあると思いますが，あまり一般的ではない技術を採用している場合，採用選考以前の問題として，そもそも対象スキルセットを有した技術者を捜すという時点で厳しいかもしれません。

また，企業買収や他部門とのシステム統合，いつか来る次期システムへのリプレース等を考慮すると，CPUのプラットフォーム等が変わることでendianで取得される値が変わってしまうとか，スケールアップを考慮しないアクティブ／スタンバイのシステムに対して業務要件を優先させるためにノンストップで切り替えなければならないといった問題があります。さらに，過去に苦労してチューニングしたシステムではあったが，昨今ではハードウェアの刷新で吸収できるという判断になった際の移行と運用の変更などなど…。

これらはいずれも技術先行ではなく，技術のトレンドと事業の趣向のバランスをいかに見分けるかという点が重要になります。