第1回　止められないシステムをどう作り、育てるか

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

はじめまして。今回「使える！サーバ運用の実践テクニック」という題目での執筆依頼をいただきました。まず、筆者が日々携わっているサイトですが、モバイル市場向けの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で取得される値が変わってしまうとか、スケールアップを考慮しないアクティブ／スタンバイのシステムに対して業務要件を優先させるためにノンストップで切り替えなければならないといった問題があります。さらに、過去に苦労してチューニングしたシステムではあったが、昨今ではハードウェアの刷新で吸収できるという判断になった際の移行と運用の変更などなど…。

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

システムを構築、維持し、スケールアップに対応するための視点

他にもさまざまな要因がありますが、こうした問題を単純に解決しようとすると「よほど必要でない限り避ける」という結論になってしまいがちです。そんな中で重要な視点を挙げるとしたら、以下のようになるでしょうか。

言語、フレームワークに関しては、サポートできるベンダ（SIer）がなるべく多いものを汎用的と定義し、追加、統合、移行（バージョンアップ）等に備える。
OS、DBなどに関しては、利用形態問わず比較的重要な部分である（障害時はアプリケーションバグ程度の問題ではない事と、反映するのに時間が必要とすることが多い）ため、保守を実施してくれるという安心感、障害時の対応力を念頭に置き選択をする。

次に、そのシステムのポリシーに関する例を挙げてみます。OSやミドルウェアを選定するポイントは、導入後にシステムが必要としている形へ機能の取捨選択が行われるべきか否かという点です。

取捨選択をしない場合、導入後に必要な定義とパッケージやアプリケーションのアドオン等、追加し続けるため肥大化したシステムになる可能性がある（余計な機能や、不要なパケットを排出するイメージ）。
取捨選択をする場合、フレームワーク自体の機能、振る舞いの意味、OS側から運用に関するメッセージの受け渡しや不要ポートの開閉などを行う必要があるが、優秀な技術者を確保する必要がある。

これらに関しては、システム計画（ルート）レベルで決定されていることは少なく、結果的にユーザによってまちまちだったりするのと、ソリューションを行うベンダやSIer等に関しても「技術者による」部分が多くて困る部分です。

ハードウェア導入に関する視点

ハードウェア側に関しても同じような側面で検討する必要があり、前提要件（SLA）を決定するため、以下のような検討を行うかと思います。

計画停止ができるシステムか？: システム（サービス）が停止できるシステムかどうかを確認する必要があります。これにより、後述の構成、ミドルウェア、アプリケーションとの調整事項等に大きく影響します。
HA（ハイアベイラビリティ／高可用性）構成か？スケールシステムか？: システム要件によるハードウェアリソース（キャパシティ）に関して影響するために決定する必要があります。また、HA構成部分がある場合、こちらに関する性能要件は早めに合意し、SLAを策定するべきでしょう。筆者個人的には可能な限りスケールで性能が担保できる部分を大きく取っておきたい、超大規模でもない限り、HA構成は避けておきたいという考えです。
故障率をどの程度で考えるか？: HA構成時の切り替えに関する保証時間、スケールシステムにおけるスケールアウト時の性能劣化を故障率として定義しておきます。また、コスト等で相談の必要はありますが、スタンバイ機器や、VMware等のリソースの分け合いで対応する運用でカバーするというのも故障率0％に近づける案となります。
処理性能はどれくらいか？: 処理性能の決定自体を重要視していない訳ではありませんが、これをプライムとした場合、性能が出ていない場合の対応が辛くなる場合があります。また、エンドユーザが不特定多数のような形態（BtoC）の場合の処理性能に関しては、ユーザ系企業であっても極力システムではなく事業立案を行う担当からの要件とした方が良いでしょう。システム担当としては、1台あたりの処理性能と増設時の性能向上率を的確に把握しておくことで、事業要件を柔軟に解決していくことに集中した方が良いと思います。

代替手段も検討する

幸いにも昨今のハードウェア（インフラ）側の進歩はめまぐるしく、最近はCPUやディスクの高速化、また、ハードウェア自体の単価下落によって、場合によってはRAIDでのミラーリング自体をハードウェアのスケールで対応したり、昔は高価だったファイバケーブルを利用したシステムもiSCSI等で代用できれば、大幅に構成がシンプル化され、障害ポイントも減り、イニシャル、運用、保守料の軽減にもつながります。

さらに昨今では、ハードウェアの仮想化までもが一般的にできるようになり、ユーザ企業にとっても大きなプラスになっていると思います。

システム構築のデザインを可能な限りスケールで対応できるような構成を前提に構築し、性能低下が許されるようなシステム（たとえばBtoC向けのシステムでは、明け方3時～5時くらいはアクセスが少ない）などであれば、その時間帯に部分的にでもマシン再起動や冗長パーツの交換等に割り当てるいった運用設計を行い、システムを構築することも可能です。

以上のようないろいろな背景から、今まで可能な限り余計なことはせずに、有償ソフトウェアや保守などでシステムを運営していた会社と担当者が、コスト削減と、運用の簡略化を目標に、オープンソースがどれくらい関与する事ができるのか？－簡単かもしれませんが、その微妙なバランスを追い求めながら、次回（⁠「⁠ハードとOS・ミドルウェアを選定する⁠」⁠）につなげさせていただければと思います。