Subscribed unsubscribe Subscribe Subscribe

SIerについてみんなに知ってほしいこと (インフラ部隊編)

雑記

以前にSIerとはなんぞや、というのを簡単に整理してみた。顧客の業務を効率化したり付加価値をつけたりする目的の情報システムを、状況に応じてカスタムメイドで作る、というのを生業としている会社のことである。

前エントリは自分の業務をバックグラウンドを共有しない人にも理解してほしいというモチベーションでまとめたものだ。今回はその続きとして、その中SIerの中をもう少しだけ覗いて、具体的に自分の業務についての解説を試みようと思う。

情報システムの構成要素

一般に情報システムは、大雑把にいって、業務要件(ビジネスロジック)をプログラムとして実装した「アプリケーション」とそのアプリケーションを動作させるコンピュータ群である「インフラストラクチャー(インフラ)」の2つから成り立っている。

単純に「情報システム」といった場合、「アプリケーション」のことを指すことも多く、その意味でインフラというのは日陰の存在、といえるかもしれない。

アプリケーションを効率的に開発したり、顧客が求めている(要件にあった)アプリを設計する方法*1を考案することは30年ぐらい前にソフトウェア工学という学問が成立したときから、常に変わらずエンジニアを悩ませる難しい問題だ。

一方のインフラは、とある人の言葉を借りると「ビジネスロジックを実装するということ以外の全て」が守備範囲となる。この曖昧な定義から、会社や文化に応じてその線引きが変わったり、アプリとインフラの間で責任分界点の綱引き(論争)が行われるということも日常茶飯事であることは容易に想像できると思う。

私が属するのは実はこのインフラを担当する部隊なのでそこをもう少し深掘ってみる。

インフラ部隊の仕事

業務要件を実装する以外の全て、というのがインフラ部隊の業務範囲であるなら、このチームのカバーする領域はとても広い。伝統的な情報システムのインフラは全て基本設計と呼ばれる設計思想を固めるところから始まり、具体的なパラメータを決めたり実際の処理やデータの流れ、エラーが起きた時の対応などを詳細設計としてまとめる。

インフラを構成する要素としては、ファシリティ(つまりデータセンタにどうやって物理筺体を配置したり、電源管理を行うか)、物理サーバ、ネットワーク、ソフトウェア(OS、ミドルウェア、フレームワーク)などがあり、さらに耐障害性や拡張性、維持管理などの方法を規定する必要がある。後半は上流工程と呼ばれる。これらを系として制御するために全体の設計を統括する役職をアーキテクトと呼ぶ*2

具体例で考える

何だか宇宙語になってきたような気がするので、少し具体例を挙げて考えてみようと思う。銀行の業務を例にとってみたい。ATMでキャッシュカードを使って、お金をおろす単純なユースケース(シナリオ)を見てみよう。

  1. あなたはATMの前にたち、タッチパネルに触れて引き出しを選択する
  2. ATMはキャッシュカードを入れるよう画面に表示する
  3. あなたはキャッシュカードをATMに挿入し暗証番号を入力する
  4. ATMの筺体はキャッシュカードから必要な情報を読み出し、暗証番号を加えて、通信路を経由して遠く離れたデータセンタにあるサーバに問い合わせを行う。結果、預金残高の情報が返却され画面上に表示される。
  5. あなたは画面上でおろしたい金額を入力する
  6. ATMはその金額をサーバに伝え、サーバはその金額分を口座から引き去り、その結果ATMはお金を物理的に出金する

ここで、ATM上で動作しあなたとやり取りをするプログラムがアプリケーションである。また、遠くはなれたデータセンタのサーバで動作する、あなたの口座情報を管理するプログラムもアプリケーションである。ATMの筺体そのものや、通信回線、データセンタにある物理的なサーバはインフラである。

あなたは間違って(もしくは意図的に?)預金残高以上の金額を出金しようとするかもしれない。そんな場合に正しくエラーとするのはアプリケーションの役割である。

ちょっと分かり難いが、ATM上やサーバ上でアプリケーションの動きを助けるソフトウェア群(OS、ミドルウェア、フレームワーク)が動作しており、これらはインフラの範囲だ*3

もし、ATMがとても人通りの多い場所にあって、利用客が多く、故障してしまうことでお金をおろせなくなった場合、銀行業務の機会損失が許容できない金額になってしまうかもしれない。そういう状況を見越して、複数台のATMを予め設置しておくことは耐障害性の考慮となりインフラの範囲である。できる設計者はもちろん機会損失のコストとATM設置のコストを天秤にかけ銀行に最適な設置を提案する。

人通りの少ない場所だったとしても、3年後に近くに駅ができて急に状況が変わるかもしれない。そのような状況に備えるためATMを追加できるように場所を確保しておくのが拡張性の設計だ。これもインフラの範囲。

今はATMに着目したが、データセンタ側も同じである。もし、サーバが1台しかないと、物理的な故障や論理的な障害が発生した際に業務が止まってしまう。そうならないような考慮が必要だ。また、将来的にATMの数はどんどん増えていくかもしれない。サーバの拡張についても考えておかなければならない。

更にいえば、運悪くATMとサーバが通信している途中に障害が発生したらどうなってしまうだろうか。もし、残高が減ったにも関わらずATMが物理的に出金しなければユーザは怒り狂うハズだ。逆に残高が減らないのに出金してしまうと銀行が怒り狂う。とすれば、この業務に限っていえば、確率的には滅多に起きないような、そんな最悪のタイミングでの障害をも考慮しなければならない*4

ちなみに、ちょろっと書いたがこのケースでは暗証番号を通信路に乗せて伝送している。ここはセキュリティの考慮が必要な部分でインフラの中。詳しく書きだすと終わらないので、ここではそういうのがあると指摘するに留めておく。

実際には何かの異常は監視しておかなければ検知することができない。ので、何をどうやってモニタリングするかも設計が必要だ。もちろん異常を検知したあとどういう対応をするかも規定するのが望ましい。ここはアプリとインフラの両方が関わる運用の世界である。

ということで

同行者からはお叱りを受けそうなラフな説明ではあるが、インフラ部隊の業務について記載してみた。そして私の業務はこのインフラの設計構築であった(今は会社を離れているので一応過去形)。そして書いてみて改めて気づいたが、やはり、バックグラウンドを共有しない人にこれを短時間で説明するのはかなり辛い。まだまだ修行は足りなそうである。

まとめ

最後に一応無理やりまとめておく。情報システムはざっくりアプリケーションとインフラで構成される。その線引について論争は尽きないが、業務要件をプログラムコードに落としこんだものがアプリケーションで、それ以外の全てがインフラである。インフラの仕事は何だかよくわからなくて地味な印象だが、長々と説明を聞けば大事そうな感じもするもので、morikenはそれを担当していた、というのがこのエントリの趣旨である*5


関連エントリ SIerについてみんなに知ってほしいこと

*1:顧客自身も往々にしてどんなシステムが欲しいかわかっていない事が多いことに注意

*2:ちなみに、私はレジメ上はアーキテクト。なぜかというと某予備校のアドバイスで「5年以上のSE経験があれば思い切ってレジメにそうと書いて良い」というのに従ったから。ただし実世界で自分のことをアーキテクトと紹介したことはない。ITの世界ではかなり恐れ多い役職なのである。実際やりにくいことを背中を押し、かつ理由を与えてくれるという意味で某予備校のカウンセラーはプロの仕事をしている(笑)

*3:アプリケーションはライブラリと呼ばれるソフトウェア部品や機能を使ったり、データベースと呼ばれるデータを安全に格納するためのプログラムを利用したりして作成される

*4:品質とコストの関係は1-e^(-x)の相似形。0を90にするのは簡単でも90を100にするコストは尋常ではない

*5:なお、香港に来る前の2年間は更に説明が難しい業務を担当していた...。あと、アプリとインフラの分けるやり方も変わっていく流れにある。