フューチャー技術ブログ

インフラ入門vol.1

1.はじめに

業務・アプリ実装からすると影のイメージがあるインフラについて、この領域をやりたいと思う人を増やすべく、インフラ入門編を記載していきます。(もちろんここでいうインフラとはITインフラのことになります)

また入門編の内容に入る前に、今回はまずは「意義」や「興味」を感じて頂くことを目的に記載します。
その後、「おっ、ちょっとやってみよう」と一歩を踏み出して頂けるような、入門ネタを記載したいと思っています。

ただ一般的な入門書に載っている内容はそちらを参照すればいいので、ここでは当社のインフラエンジニアがスキルを身に付けていく過程の入門ネタを書き連ねたいと思っています。(結局、一般的なことになった場合はすみません)

なお、本内容は筆者の主張が含まれておりますのでご了承ください。

もぜひご参考ください。

2.インフラって何?

そもそもインフラって何でしょうか。
正しい名称は、インフラストラクチャー (infrastructure)で、Wikipediaには以下の記載があります。

インフラストラクチャー (英語: infrastructure) とは、「下支えするもの」「下部構造」を指す観念的な用語であり、以下の意味がある。

  • 国民福祉の向上と国民経済の発展に必要な公共施設。
  • 企業などの主幹となる設備。

https://ja.wikipedia.org/wiki/インフラストラクチャー

ITインフラというと、ITの仕組み(アプリケーション)を「下支えするもの」というイメージですね。
具体的に、ITのインフラでイメージされるのは、ネットワーク、ハードウェア、OS、各種ミドルウェア等・・・といったところでしょうか。

ただここで、外してはいけないことがあります。
「下支えするもの」ということです。その上で動いている仕組みを動かしてあげると言う点です。
重要なのは、先ほどの、ネットワーク、ハードウェア、OS、各種ミドルウェア等といったところがITインフラの目的となってはいけないということです。
ITインフラで下支えする仕組みとは、システムを利用するユーザが求める機能(=アプリケーション)になります。
当社のお仕事でいうところの顧客の業務処理(業務アプリケーション)ですね。

以降は業務アプリケーションの例を元に記載します。

アプリケーションは、パッケージ製品など出来合いのものもありますが、求められる機能に対してプログラムでコーディングされたものになります。
ITインフラはこれを「下支えするもの」である必要があります。
そういう意味で、インフラとは簡単に言うと、プログラムでコーディングされるもの”以外全て”となります。
少し話しは外れますが、インフラにあまり興味が無い方や初めての方は以下のようなマイナスなイメージがあるのではないでしょうか。

  • 製品だから動いて当たり前
  • マニュアルを見て設定すれば終わりなのでクリエイティブなものは無い
  • 色々なアプリの要求に泥臭く対応する必要がある
  • 製品ベンダでもない限り、モノづくり感はない など

インフラレイヤはコーディングしてゼロから何かを生み出すものではないので、そうかもしれません。
(昨今の Infrastructure as Codeのためのコーディングや、また当社はたまにハードも作ってますがそういった例も除く)

ただ、逆に言うとコーディング以外の全てを誰かがお膳立てする必要があります。
それがインフラです。

またこのお膳立ての内容は自宅のサーバー機器でもない限り、単純には行きません。
結果的に設計が単純だったとしても、そこに行きつくまでの要件定義や技術検証、インフラデザインには経験と知識が必要 になります。

顧客の予算・業務要件を加味しつつ、将来の技術要素のトレンドも見据え、動いて当たり前の品質を実現するのには何をどうデザインし、採用技術を決め、実装・テストのスケジュールを立てるのか…
そのあたりがインフラの醍醐味となります。

なお、私的な意見ですが、デザインまで終われば基本的には後は設定作業になります。
よほど難解な要件や新技術要素の導入が無い限り、ここに醍醐味はありません。
インフラに興味のない方の多くは、その設定作業のみ見えている方かもしれません。

3.インフラエンジニアに求められること

前述の通り、期待されるのは、システムを利用するユーザが求める機能(=アプリケーション)を下支えすること。
対象は、そのアプリケーションプログラムでコーディングされるもの”以外全て”となります。

その手段の種別として、ネットワーク、ハードウェア、OS、各種ミドルウェア等があり、それぞれ個の領域に特化された方、フルスタックに検討出来る方など、人によって濃淡はありますが、総じてアプリケーションを期待どおりに動かすインフラを提供する必要があります。
もちろんその利用者の要求する機能(アプリケーション)を支えるインフラである必要があり、また非機能要件も考慮して、インフラの手段に落とすことが求められます。

またインフラはアプリケーションの開発やテストに先行して環境を提供する必要があります。
特にネットワークについてはWAN等、工事に期間を要するものもあるためアプリケーションの全貌が見えない中で準備を開始するケースもあります。

上記に対して必要な基礎知識は以下の通りです。

  1. インフラ手段の知識や要件に見合った、動いて当たり前の環境を設計するデザインセンス
  2. アプリケーション開発をお膳立てするための先回りした計画力
  3. インフラを分からない人にでも非機能面や選定製品の根拠を説明でき、予算とともに合意していく交渉力

入門編としては(1)のお話ができればと思っています。
なお、(1),(2)は経験を積めば着実に身に付く知識ですが、(3)はある程度、その人の人間力や性格にもよります。

4.「インフラ手段の知識や要件に見合った、動いて当たり前の環境を設計するデザインセンス」の前提

このデザインセンスとは、結局のところ、要件に見合った当たり前のインフラ環境を設計し、それを想定通りに本番稼働させるセンスとなります。
ここでもやはり外してはいけないのが、インフラを想定通りに稼働させるのはもちろんですが、目的はインフラが下支えしている業務アプリケーションが想定通りに動くことです。
アプリケーションはプログラムのコーディングに依存するので、インフラとしてはどうしようもないのでは?という話ではありません。

インフラでは非機能要件で性能や可用性を定義し、それを担保するためのミドルウェアや技術要素を設計します。
プログラムのコーディングロジック以前の処理方式を決めているのです。

そこで重要なのが、当たり前なのですが、アプリケーションに求められる処理方式をイメージする必要があります。
インフラはアプリケーションの開発前に製品を発注する必要があるため、アプリケーションの要件定義・基本設計時点でそれらをイメージしきる必要があります。
それには、何をするシステムなのかを、データのインプットとアウトプットのフロー(ユーザやシステムとのインターフェース)をイメージし、必要なデータの形式やシステム内外のプロトコルなどを組み上げておく必要があります。

また非機能面でいうと、業務的に止めてはいけない機能や、リアルタイム性が必要な機能、サイジングに関わるデータ量などを押さえておく必要もあります。
製品や技術要素の選定には運用スキームも想定する必要もあります。

そこで大切なのは、また当たり前ですが、そのイメージをアプリケーション開発のキーマンとズレがないように、コミュニケーションすることです。
もちろん修正が必要なケースもありますが、その場合もアプリケーションとインフラで意識を合わせながら検討できる見通しの良いチームの環境つくりが重要です。
インフラが成功するかどうかは、私はここが一番のポイントだと考えています。

インフラの技術要素に閉じた中での問題は大概何とでも潰しが効くと思いますが、そもそもの処理方式のイメージが違う場合、修正は困難なものとなります。
例えると、ミニバンが欲しい人にスポーツカーを押し売るイメージでしょうか。

5.「インフラ手段の知識や要件に見合った、動いて当たり前の環境を設計するデザインセンス」入門に向けて

さて、前置きが長くなりましたが、インフラの入門ネタとして、知っておくべき各インフラのパートをご紹介します。

また業務アプリケーションを支えるインフラが提供するサービス(役割)としては、基本的に以下のような種類に分かれます。

  • WEB: 画面からのWebアクセスやAPIなどのWebサービスを受け付け、応答を返す、出入り口
  • AP: アプリケーションのロジックを動かす
  • DB: データの保管、取り出しを担う
  • 帳票: ExcelやPDFなど帳票レポートの出力を行う
  • データ連携: EDIやEAIなどファイルやメッセージで他と通信する
  • ジョブ管理: 自動実行のタイムコントロールや順序制御を行う
  • 監視通知: 障害の検知や業務に必要な通知を実施
  • バックアップ: データやシステムのバックアップ、およびリストアを実施
  • 他システム運用系サービス: ログイン認証、ログの管理、ウィルス対策等を実現

これらの役割に対して、ネットワーク、ハードウェア、OS、各種ミドルウェア等といった、インフラのパーツ・手段を設計することとなります。
責任をもって想定通りに業務アプリケーションを下支えするためには、様々な構成パタンや製品を選定するうえで、何を理解して、押さえておく必要があるのでしょうか。

次回以降のインフラ入門編で、個別の領域ごとに、まずはとっかかりとして理解しておくべきことをご説明していきます。

6.次回

ということで、今回はインフラ入門の前提となる話を中心に書き連ねました。
次回からはインフラの個別領域に絞った入門ネタのお話を掲載できればと考えています。