【インフラデザイン】インフラ初心者の机上学習　〜　インフラのグランドデザイン

【前置き】
昨年2013年の秋ごろからインフラの仕事に関わっている。恥ずかしいことに、それまでインフラの仕事を殆どしたことがなかった。書籍で勉強したことはあったが、プロジェクトに参画するという実戦は初めて。これまでのキャリアが、如何にアプリケーション側に偏っていたかを痛感している。

アプリケーションのデザインを考える際には、GoFのデザインパターンが基礎となるだろう。他にも、デザインパターンではないが、WebアプリだとCSSスプライトやメモ化や遅延ロードなどなど、幾つかパターンと呼んでもいいものがある。SIerなので、バリバリコーディングしているわけでもなく、むしろExcelやパワポをいじっていることの方が残念ながら多いため、全てを忘れずに覚えているわけではないが、たいてい経験はあるわけ。

しかし、インフラで、アプリケーションのデザインパターンに相当するものは何かと問われても、全く思い浮かばいない。それどころか、何から手をつけて、何をゴールとすれば良いのかすら分からない。そんな状況に置かれながら、実戦を積みながら数ヶ月が経ったわけだ。プロジェクトは非常に混沌としていたため、残念ながらインフラのパターンを身につけることはできなかったものの、経験値はあがった。そして今、（相変わらず忙しいが）前プロジェクトが一段落ついたため、このタイミングでインフラ構築とは何か？インフラのデザインパターンは何か？を広く浅く眺めようと思っている。

【本題】
そう思って、まずはグーグル先生に質問したｗ。
そしたらありました。「ITを真の武器とするためのインフラのグランドデザイン」。
たしかに、デザインパターンと言っても複数あるが、まずは全体像を抑えることが重要。
そこで今回は、この記事をベースに「インフラのグランドデザイン」について概要を抑えることを目的として学習した結果をメモしておく。

2010年の古い記事。4年を経て書籍化されたようだ。NTTデータは嫌いだが、SIerでそれなりの「書類」を揃えている所が少ないのも事実かな？：ITを真の武器とするためのインフラのグランドデザイン http://t.co/0KA3rHhZTN @itleaders_jpさんから
— graySpace (@graySpace999) 2014, 6月 18

さて、記事を読む前に、そもそもの学習目的を忘れないようにしておく。次の図の１〜５を知りたいと思って始めたのだ。

１．ゴールは何？
これに関する記述は見当たらなかったので自分なりに考えてみた。
大きくこの2つに分類できるかと思う。

まず、「1-1.新規開発時」。
①最終的な目的であり、　最大の動機は「アプリケーション作成」だと思う。
そして、それを達成するためにインフラ基盤が必要だというのが、インフラ基盤が求められているものではないかと思う。

次に、「1-2.移行時」。
アプリケーションの言語変更やクライアント・サーバシステムからWEB化への刷新など、様々な要因で移行が必要となる。

２．スタートはどこ？
「１．ゴールは何？」で記載した図に書いたように、新規開発時は「アプリケーションを作成したい」という動機がスタートだと考える。そして、それを動かすためにインフラが必要となる。つまり、インフラ構築といえど、アプリケーションありきだと考えている。
移行時も、「アプリケーションの移行を発端としたインフラ移行」の場合はアプリケーションがスタートとなるだろう。ただ、移行の場合は、「OSを刷新したい、DBを別の製品に変更したいといったインフラ更改を発端としたインフラ移行」もあるので、必ずしもアプリケーションありきとはいえないだろう。この場合は、逆に、インフラ更改が発端となり、アプリケーションの更改が必要になる場合もある*1。

３．スタートするには何が必要？
この辺りから、記事にもヒントが登場する。
移行の場合だが、記事の図を引用すると「現状システム分析」が必要となる。これに加えて、移行要件の確認と整理も必要だろう。つまり、顧客はなぜ移行が必要なのかを、RASIS(信頼性、可用性、保守性、保全性、安全性）の観点から整理する。さらにこれを、コスト削減の観点で整理することも必要だろう。
（「ITを真の武器とするためのインフラのグランドデザイン」から引用。）
以下、記事からポイントを纏める。

①全システムを棚卸して各システムの目的や経営上の位置づけを整理し、ITポートフォリオとして見える化する。
②マッピング結果を確認し、ポジションの近いシステム群をグループ化してシステム基盤統合の検討対象とする。
③検討対象となる各システムの非機能要求やシステム構成、利用製品、リソース使用率、ライフサイクルなどを詳細に調査し、需要予測のかい離やシステム運用上の問題点といった課題を整理しておく。

ITポートフォリオを作成した経験は無いが、こういうものもあるということで、今後は作成していきたい。
（「ITを真の武器とするためのインフラのグランドデザイン」から引用。）

現行システムの非機能要求があいまいになっていることが多い

これは「あるある」話だ。例えば、移行環境を構築する際の指標として、業務データ量、同時最大接続数、単位時間あたりのトランザクション数、最低レスポンス時間 etcをヒアリングするが、「決まりが存在しない」「現システム担当者が把握していない」といったことが多々ある。これでは、移行先環境構築のインプットとなる移行元環境の指標がないため、ゴールを定められない。しかし、進めなければならないので、想定されうる要件を整理しながらヒアリング・調査をしていくことになる。

４．スタートからゴールに辿り着くのに足りないものは？
残念ながら、足りないものは沢山出てくるので、1つ1つ抜け漏れが内容に整理して、確認していくしか無いだろう。
その手助けとして、非機能要求グレード表、インフラデザインパターンがあるので、これらを利用すれば良いだろう。

５．スタートからゴールに向かう途中で乗り越えるべき壁は？
ここは記事の内容をそのまま引用する。

現行システムから次期システム統合基盤への移行を検討し、各システムの移行スケジュールを作成する。具体的には、移行のタイミングがサービスのピーク時期と重複してないかや、アプリケーションの更改時期、保守期限切れ時期などを考慮する必要がある。また、各システムの移行における課題やリスクがあれば整理しておき、影響を受けるイベントやその対応について調整し、長期的なシナリオとしてまとめる。
大切なのは、ビジネス環境の変化や新たな技術革新があった場合、ロードマップの途中でも見直しできるように手順や考え方を整理しておくことだ。

今回の内容はここまで。
次回以降は、せっかく次の本を購入したので、内容に触れながら1つ1つパターンを身につけていきたい。最初は机上学習だけど・・・。