１．本記事の目的について
社員の皆様お疲れ様です。バルテックの飯田(はんだ)です。研修生の大半の方がJavaなどの開発言語を学ばれて現場へ出て行く中
私はバルテックでは数少ないインフラ系のSEをやっております。
今回は以下の2点を目的としています。
①研修生の方々や開発系の方々へ「インフラ系とはどんな業務なのか」を
できる限り分かりやすく簡潔に紹介すること、
②今後インフラに進まれる方へのある程度の指標値としてもらえること
特にネットワークの勉強をして、これからインフラの現場に入る方。
まずはインフラ担当業務及び、キャリアアップの未知に対するイメージを持っていただいて、
さらにサーバ側にも興味を持っていただきたく思っています。
運よくネットワークの案件に入れる方もいらっしゃるでしょうが
案件としてはネットワークよりもサーバのほうが多いですし、
サーバの案件では何をしているかについては興味を持ってもらった方が
今後の道が広がると思います。
私もバルテックに入る前にCCNAを取得しております。
ですが、インフラのエンジニアをやる上で
ネットワーク機器の構築、保守を行わない限り、
ネットワークについてはMAC、IP、NATやSTP、VLANなどのネットワークの基本概念が理解できていればいいのではないかと今は考えています。
なお、できるだけ簡潔にするため、一部詳細を追えば違うところがあったりしますが
今回はイメージを持ってもらうことが目的ですので、
そこは現場に入って勉強するなりで各々修正してください。
２．インフラってそもそもなに？
まずインフラって何だろうと、そこから入ってみます。インフラとは
Infrastructure(インフラストラクチャー 意味はgoogole先生に聞いてください。)
の略です。
皆さんからすると社会インフラ、つまり電気・ガス・水道、
もしくは電車や電話、病院などを思い浮かべるのではないでしょうか。
電気、ガス、水道はお風呂に入ったり、テレビを見たりするのに使います。
電車や電話なども含め現代人が生活をする上でほぼ必要不可欠となっています。
ITにおけるインフラも考え方としては同じです。
システムを動かす上で、なくてはならないものとなります。
３．ITにおけるインフラって？？
ここまでの説明で「だから何？漠然としていてよく分からないんですけど・・・」と思うはずです。
思わない人はこの記事自体を読む必要がないほどよく分かってらっしゃいます。
一言で言えば変態です。
・・・さて、ITにおけるインフラといっても色々ありますので、順番に説明します。
システムが動作している環境は、
サーバの筐体やストレージ装置、
ルータ、スイッチなど
ネットワークの機械(ハードウェア)があります。
各機器はそれぞれの用途に応じて連携しています。
各機器について役割を書いていくと
サーバ：アプリケーションを動作(WEB／AP／DB)
ストレージ：データを保存
(主にサーバの大量データを保存)
ルータ：論理的なネットワークを接続(IPアドレス)
スイッチ：物理的なネットワークを接続
(MACアドレス)
といった形になっています。
次は各々の立場で見えている構成について説明します。
エンドユーザ側が考えている構成、普通にWEBページを使う上でシステムを何も知らない人が考えている構成はこんな感じと思います。
で、業務アプリを作る側、つまり開発側が意識する構成はこんな感じと思います。
場合によってはルータも意識しないかもしれません。
私が11月までいた現場はさほど大きなシステムではありませんでしたが
これよりも遥かに複雑でした。
後の項目で説明しますが、
左図は冗長化や負荷分散の観点で
システムとして可用性が不十分です。
回答は後の項目で行います。
まずはこの項目の結論を挙げておきます。
ITにおけるインフラとは
エンドユーザ及び、開発側が意識しない部分の作成、運用、保守
が役割です。
ネットワーク担当、サーバ担当、ハードウェア担当
それぞれにおいてこの点は変わりません。
４．サーバの中身について
さて、項番３では大まかに各機器の役割を挙げましたが、
今回はサーバについてもう少し細部まで挙げてみます。
ネットワーク機器やストレージ装置にはプラグインを組み込むことはありますが
基本的にはファームウェアの機能のみで動作しているので今回は省略します。
ベンダーアプリの中には皆さんが開発したアプリケーションを乗せていきます。
インフラ業務とは左図の開発担当と書いた部分以外全てとなります。
開発担当の方も現場によっては
TomcatやApache、OracleDBの設定を行うことがあるかもしれません。
それは立派なインフラ業務です。
５．システムが出来上がるまでの大まかな流れ
４．サーバの中身で述べた通り、業務アプリケーション以外は全てインフラ業務となります。
サーバ以外のネットワーク機器やストレージについてもインフラとなります。
今回はシステムが構築し、運用され、そして更改されるまでの流れについて
本来はもっと多くの工程がありますが、非常にざっくり説明します。
５．１ 要件定義(設計担当)
まずはエンドユーザとSIer企業にて「○○っといった機能がほしい。」
「××といったサービスを今後顧客に提供したいので、そのシステムを作ってほしい」
といった大まかな機能について話し合い、システムの方針を決めます。
それに合わせて
・実装可能か否か
・実装する場合はどのハードウェアが、OSが、ベンダーアプリが適切か
・コストや開発期間はどのくらいか
などを決定します。
これを前現場では基本設計と呼んでいました。
他の現場でも大きく変わらないと思われます。
５．２ 方式設計(設計担当)
要件定義で決めた実装方式について詳細にどのようにして行うのかを決めます。・APとDBの連携方式
・バックアップを○○の製品で取得し、××に保存する方式
・災害発生時にどういった運用へ変更する方式
などを実現した際の影響などを含め、詳細に設計します。
５．３ 環境設計(設計担当)
５．２の方式設計を実際のサーバにどういった設定を入れれば設計どおりになるかを設定ファイルの記載内容やサービス設定レベルで決定します。
５．４ システム構築(構築担当)
５．３ 環境設計の内容を実際にサーバやネットワーク機器に設定します。５．５ テスト(構築担当)
・ 構築したサーバのみの動作確認を行う単体テスト・ 複数サーバや複数アプリケーションでの動作確認を業務アプリを絡めて行う結合テスト
・ システム全体としての動作や性能面、更にはシステム間での確認を行ったり、
実際に障害が出た際にどういった対処を取るかを運用設計で行い
運用時に想定どおりの動作が可能か否かを確認する運用テスト
など、順に構築したシステムで
要件定義で決定した内容が実際に動作できているか否かを確認します。
５．６ 運用・保守(運用、保守担当)
実際にサービスを開始し、構築時に拾い切れなかった不具合やハード故障発生時などにシステムが正常になるようにします。
主に以下の流れとなります。
障害発生＞エラー検知＞暫定対処＞ログ・ダンプ採取＞原因調査＞本格対処
５．７ システム更改(設計担当)
ハードウェアやソフトウェアのサポート期限切れシステム増改築などが必要となった場合に再び要件定義から順に行います。
６．インフラ担当の業務内容及びキャリアプランについて
５．システムが出来上がるまでの流れで述べた各フェーズでインフラ担当者の業務がありますが大きく分けて「設計・構築・運用／保守」の３つです。
実際にやってみないとよく分からないと思いますので、各担当の内容については現時点で理解する必要はありません。
なんとなく分かってもらえれば結構です。
まずはキャリアプランの概略図です。図のように、運用オペレータから始まり、保守＞構築＞設計と流れるのが一般的です。難易度も大体図の通りに上がっていきます。
では各担当における業務内容を説明しますが、量が多いです。
インフラ以外の方は斜め読みしていただいてもかまいません。
(１)運用オペレータ
大体の場合で、インフラ担当者の一番初めに従事する業務は運用オペレータになります。場合によってはほかから入ることもありますが、残念ながらインフラ設計などに強い会社の新人を教育を含めて行う場合などとなりますので、バルテックのインフラはまだその段階ではありません。
メインとなる業務内容は以下の３つです。
①定められた手順での障害発生時の一次切り分け及び、保守部署へのエスカレーション
②一次切り分けの結果定められた手順で復旧可能な場合の復旧対応
③定められた手順での定常的なシステムの状態確認
私も運用オペレータを2年弱行いましたが、上記以外にも以下のような業務がありました。
・顧客PCのヘルプデスク
・MTA(メールの振り分け)装置のサポート受付
・ハード故障時のCE手配及び時間調整、顧客折衝
主に24時間365日対応することとなる部署が多く、夜勤及び土日出勤、
更に祝日がある月も稼動が変わりません。
しかし、うまく回っているような部署では残業が０どころか、突き当たり平均稼動が140時間前後と
障害が発生しておらず、更に定常業務時間外であれば、仕事自体がないため自分の時間が非常に取りづらく、空いた時間を使って資格の勉強などに当てやすい業務ではあります。
私が従事した現場ではNGでしたが、部署によってはPSPなどで遊べたりもするそうです。
また、メイン業務のそれぞれにわざわざ「定められた手順」と書いたことにも理由があり
定められたこと以外の対応は禁止です。
個人的にははじめの段階で楽を覚えてしまうと、将来的に心配なので
空き時間に何かしらの分野の勉強を行って、早めに卒業することをお勧めします。
(２)保守SE
運用オペレータなどからエスカレーションされた障害に対し影響確認＞暫定対処＞ログ収集＞原因調査＞本格対処＞設計書修正
といった流れとなります。(障害の二次受け)
主に「設計通りに動作しなかった原因を究明、修正」をすることがメインの対応です。
その他顧客のQ/Aや、機能追加時の影響調査なども行うことがあります。
担当システムの動作について理解しておかなければ対処ができない上に
自分で構築したシステムではないにもかかわらず、システムについて熟知する必要があるため、
運用オペレータに比べ難易度は遥かに上がります。
(３)保守CE
ハードウェアの修理及び障害対応などを担当します。機器の状態、ログの採取方法などがマニュアルに記載されており、手順に従って対応します。
主に製品開発時に手順が確定してありますので、手順作成などは行いません。
(４)構築SE
設計された内容を設計書通りにサーバやネットワーク機器に適用し、問題なく動作するかを試験します。部署によりますが、設計書を手順書に起こす対応もあり、ある程度システムへの理解がされていないと対応時に困ります。(５)製品サポート
システムで使用している製品に特化したスペシャリスト部隊です。製品開発部署の手前に配置され、顧客や各SE、CEの質問受付、回答などを行います。
難解なマニュアルもあり、製品について熟知している必要があります。
(６)設計SE
顧客の要望した機能を実際にシステムに搭載するためのHW、OS、PPそれぞれにおいて決定し、設計書を記載します。顧客の要望が実現可能か否か、行う際にどういった仕組みを提供しなければならないか
構築にかかる工数などなど、インフラについて熟知する必要があり、特に新規システムについては設計・構築経験が必須です。
OS設計、各種PP設計、ストレージ設計、ネットワーク設計、運用設計などなど
各設計部署に分かれます。
(７)まとめ
現場によっては設計・構築・保守まで全てひとつの部署で行っているようなところもあったりサポート部署や、構築オペレータなどがあったりする部署もあります。
補足までに、私の経歴は以下の通りです。
保守CE：2ヶ月
運用オペレータ：1年9ヶ月
保守SE：1年7ヶ月
運用オペレータはバルテックに入社する前に従事してました。
12月からは構築SEをやります。
７．インフラ技術例
インフラ業務の各担当については
「いろいろあるんだなー」程度には分かってもらえたかと思います。
「３．ITにおけるインフラって？？」でも表示した物理構成についてですが、問題を1問出しておりましたね。「この構成では可用性面で問題がある」と。
回答の前にいくつかインフラにおける冗長性確保の技術について説明します。
７．１ ロードバランス(負荷分散)について
WEBサーバが3台ありますが、今回の場合それぞれが同じ役割を果たしています。アクセスが集中すると、1台のサーバでは処理しきれないような大量のデータを受け取ることがあります。
大量のデータを取得した場合、場合によってはタイムアウトして処理が止まってしまいます。
そこでロードバランシングといった技術で、負荷分散を行います。
簡単に言うと、１つ目の接続はWEBサーバ１、２つ目の接続はWEBサーバ２、３つ目の接続はWEBサーバ３、４つ目はまたWEBサーバ１に接続させるように設定することにより、１台辺りの受け取りデータ量を1/3にできるわけです。
また冗長性も保っており、たとえばWEBサーバ２が壊れてしまって起動しない場合も、残り2つのサーバで業務が継続できます。この業務が継続できる仕組みのことをBCP(Business Continuely Project＝事業継続性)といいます。IBMとかがCMでたまにやってますので、聞いたことがあるのではないでしょうか。
また、議題になった可用性についてはシステムが動作している時間の割合のことです。
基本情報処理などでは「可用性を99.99％にするためには年間辺り何時間停止することができるか」などと挙げられています。
興味がある方は勉強してみてください。
SEをやる上で、基本情報の知識はかなり役に立ちます。
取っておいて損はない資格です。
７．２ スイッチの冗長性について
CCNAを勉強している人はご存知でしょうが、スイッチを2台配置していることには訳があります。物理構成図とはいえ少し簡略して書いています。
スイッチ１、スイッチ２と各サーバは共に1本のLANケーブルで接続されています。
APDBサーバとスイッチの部分を詳細に書くと
こんな感じです。
ここでスイッチ２が故障したとします。
すると、当然スイッチ２から出ている経路(スイッチ2に接続されている経路)は使えなくなります。
ですが、APDBサーバ１、２共にスイッチ１からも接続されているので、APDBサーバへの接続が途絶えることはありません。
７．３ クラスタリングについて
クラスタ環境といった言葉を聞いたことがある人もいるかもしれません。APDBサーバ１とAPDBサーバ２は現用機、待機機として動作させています。
普段は現用機だけで動かしておき、APDBサーバ１が故障やハングアップした際に、APDBサーバ２で業務を行うといった運用方式を取ります。これをクラスタリングと呼びます。
ロードバランス方式との違いは、データベースは同じ領域に書き込みを行います。
複数のサーバで運用すると、同じ部分に対して同時に書き込みを行い、
ファイルシステムが壊れてしまいます。
なぜ壊れるかを説明すると長くなるので省きますが、データの書き込みを行う際にロードバランスで負荷分散はできないと思ってください。
７．４ 構成の問題点について
さて、何点かの冗長化について説明してきました。問題として出していたものは「この構成では可用性に問題がある」でしたが
分かってもらえたでしょうか。
そう、ルータが1台しかなく、ルータ周りが故障してしまうとシステムに全く接続できなくなります。
こういった構成にならないように設計する必要があるわけですね。
８． まとめ
インフラ担当者の業務内容について非常にざくっと説明しましたがなんとなく分かってもらえたでしょうか。
皆さんが開発したアプリケーションはサーバに搭載され、ネットワークを通じて結果を返します。
インフラはシステムを動かす上で必須なんです。
インフラが整っていないと、せっかく作成したアプリケーションも動作しなかったりします。
この記事を通して開発担当の方も、今後インフラ業務へ入る方も
少しでもインフラ業務に対して理解が深まると幸いです。
