インフラエンジニアのおしごと
読書対象者
- 駆け出しPM、駆け出しアプリ開発者でインフラのことをざっくり知りたい人
- 駆け出しインフラエンジニア
- 駆け出し基本情報処理試験勉強者
- 駆け出したけど転んだ人
インフラってなんだろな？
・インフラとは、「アプリをつくってぽんっっと、のっけたら動く環境」のこと。
・アプリ開発者は、インフラをインフラチームに任せることで、アプリ開発に集中できる。
インフラは、アプリケーションが安心して動く環境なんだ〜と思えばだいたいあってる。
難しい言葉で言うと、こんな感じ：
ITインフラとは、情報システムを稼動させる基盤となるコンピュータなどの機材、ソフトウェアやデータ、通信回線やネットワークなどの総体のこと。「インフラストラクチャ」（infrastructure）は基盤、土台、下部構造などの意。
ITインフラ 【 IT infrastructure 】 IT基盤 / システムインフラより引用
アプリケーションが動くための基盤となる環境そのものをインフラって呼ぶんだね〜。
なんで、インフラ（Infrastructure＝基盤）っていうかというと、
安心して動く環境の構成って、だいたい同じで、パターン化してるからかな〜。
だって、インフラって一部が壊れても、アプリケーション（サービス）が動き続けてくれるようになってんだよ、すごいじゃんね。
でも、インフラが安心して動くためには、中身をいろいろ知ってないといけないね〜。
インフラってなーに？なーに？なーに？
具体的な話をしたほうがイメージできるかもね？
| 機器 | せつめい |
|---|---|
| ①FW | ファイアウォール。外から変な通信が来ないようにしたり、中から大切なデータが外へ出ていかないように制御してる。 |
| ②RouterなどNW機器 | Router、L3スイッチ、L2スイッチなどを組み合わせて、各種システムが独立性を保ちつつ、通信を効率よくさせるようなためのネットワークを制御している。 |
| ③LB | ロードバランサー。負荷分散装置。主に1台のWebサーバにアクセスが集中しないように制御する。 |
| ④Webサーバ | フロントエンドアプリを載せるところ。コンテンツを探してなければ404を返したりりしてる。 |
| ⑤Appサーバ | バックエンドアプリを載せるところ。DBへの接続を効率よく行ったりしてる。 |
| ⑥DBサーバ | データを効率よく保存するための機能。データを効率よく読み出すための機能 |
| ⑦FCスイッチ | DBサーバとストレージを光ケーブルでつないでる中間装置。 |
| ⑧ストレージ | 大量のデータを効率よく安全に保存できる装置。 |
ここに載せているのはサンプルにすぎず、例えば以下のようなものもインフラに含まれます。
| 機能 | せつめい |
|---|---|
| 認証 | ログインに利用する認証機能。キーワードとしては、公開鍵認証など。 |
| キューイング | システム間でデータをやり取りするための中間機能。これを利用することでシステム感の接続を疎結合にしたり、一つのデータを複数システムで利用できたりする。 |
| ftp | ファイル転送。最近ではsftpが主流。ホームページをuploadする際に使ったり、サーバからログファイルをダウンロードする際に使ったりする。 |
| メール | メールの送受信。監視システムがシステムのログからエラーを検知してメールする、などで使われる。 |
| 監視 | システムの異常を早期に検知するための仕組み。プロセスが落ちたのを検知したり、ログのエラーを検知したりする。 |
| ジョブ/バッチ | 定期的にアプリケーションを実行するための仕組み。例えば、1日1回バックアップを取得するとか。1ヶ月に1回再起動するとか。 |
インフラエンジニアのおしごと
さてっと。インフラのイメージがなんとなく湧いたところで、今度は、インフラエンジニアのおしごとの話だ。
インフラエンジニアの仕事は、構築フェーズとして、
- アプリケーションの理解（サービスレベルの理解）
- インフラ設計
- インフラ構築（テスト含む）してアプリケーションチームへ引き渡し
後は、運用・保守フェーズとして、インフラ運用・保守
ってことをやってるよ。
どのフェーズの何をやるかで、求められるスキルも変わってくるので、
まずは全体としてどういうしごとがあるのかを理解しちゃおっ！
| かてごり | おしごとの説明 | 一言で言うと？ |
|---|---|---|
| アプリの理解 | 何のためにインフラを作るのかを理解するおしごと | アプリ理解 |
| インフラ設計① | システムがどことつながってるか図示するおしごと | システム概要 |
| インフラ設計② | インフラ死亡時にアプリが止まらないように考えるおしごと | 信頼性設計 |
| インフラ設計③ | 外部からの攻撃とかウイルスを防ぐ方法を考えるおしごと | セキュリティ設計 |
| インフラ設計④ | 問題発生を早めにキャッチする方法を考えるおしごと | 運用設計（問題検知） |
| インフラ設計⑤ | 問題が起こらないように準備する方法を考えるおしごと | 運用設計（予防保守） |
| インフラ設計⑥ | 問題が起こったときに早めに治す方法を考えるおしごと | 運用設計（障害対応） |
| インフラ構築 | 設計で決めた内容をがんばってつくるおしごと | インフラ構築 |
| インフラ運用・保守① | 問題発生を早めにキャッチするおしごと | 問題検知 |
| インフラ運用・保守② | 問題が起こらないように準備するおしごと | 予防保守 |
| インフラ運用・保守③ | 問題が起こったときに早めに治すおしごと | 障害対応 |
ではいっこいっこ掘り下げていくよ〜。気楽にね。
1.アプリの理解
以外にこれ知らないでインフラ作っちゃうケースは多いんだよね。
でも、これとっても重要です！！！！！
提供している機能のどれが重要なのか、を明確にしておかないと、構築時の設計も間違っちゃうし、何より運用・保守フェーズで、即座の対応が必要なのか、明日でいいや〜くらいの対応でよいのかの判断が難しくなってしまうのだ。
なので、アプリケーションの機能や利用しているユーザなどはちゃんとヒアリングして理解しよ〜。
優先順位高い機能は、例えば、お金に関する機能（入出金や有価証券の売買）とか、
優先順位低い機能は、例えばお知らせ機能で、他に代替手段があるやつとか、ですね。
2.システム概要
システム概要図を作ること、超重要！
これがあると関係者（ステークホルダー）との認識合わせがしやすくなるので、早い段階で作るとほんと効果的。
あとは、金融庁や監査対応などで、概要図があると説明した際に理解してもらいやすくなるので、本当にオススメ。細かくしすぎると更新が面倒になるので、ざっくりでよい。
- 登場人物の図示（顧客、自社、自社業務部門、自社別サービス、他社サービス）
- 顧客向け機能、自社業務部門向け機能のうち、主要なものを記載
- システム処理なのか、手動（オペレーション）処理なのかを記載。
- リアルタイム処理なのか、定期的に動くバッチ（ジョブ）処理なのかを記載。
仮想通貨取引所のサンプルはこんな感じ〜
3.信頼性設計
これが一番の肝だよ〜〜
インフラ構成は、基本的に、SPOF（Single Point of failure）で構成される。
例えば、2台構成で、壊れる可能性が1%の機器があった場合、
2台同時に壊れる可能性は、0.01×0.01=0.0001となり、0.01%と、大幅に信頼性が向上する。
この信頼性設計は、主に下記の3パターンで構成される。
| 信頼性構成 | せつめい | 使われる場所 |
|---|---|---|
| Active-Standby | ActiveからStanbyに切り替わることをFailoverと呼ぶため、Failover構成とも呼ばれる。また、HA(High Availability)クラスタとも呼ばれる。 | DB、ストレージ、FW |
| Active-Active | 2台両方ともActiveとして利用し、1台死んだときには縮退して1台のまま運用ができる構成。 | NW、DB(OracleRAC）、LB |
| Load Balance | 3台以上をActiveとして利用し、1台死んだときには縮退して残りの台数で運用ができる構成。 | WEB、APP |
4.セキュリティ設計
| カテゴリ | 説明 | 機器 |
|---|---|---|
| 入口対策 | ACL(Access Control List）を利用してIP/Port番号で入ってくる通信を制御する。特定の通信元からしか通信を許可しない。 | FW |
| 入口対策 | あああああ。 | IDS/IPS |
| 入口対策 | ああああ | WAF（WebApplicationFirewall |
| 内部対策 | ログ監視 | 監視ソフト |
| 内部対策 | ファイル暗号化 | あああ |
| 内部対策 | ウイルス対策 | NW、DB(OracleRAC） |
| 出口対策 | ACL(Access Control List）を利用してIP/Port番号で入ってくる通信を制御する。特定の通信元からしか通信を許可しない。 | FW |
参考：IPAの資料 わかりやすい。
5.運用設計（問題検知）
- システムの異常を定義（アプリログにErrorが出たら、とか。5分以内に10回以上出たら、とか。）
- システムの異常を検知（監視の仕組み）
- 検知後のエスカレーション方法を定義（誰が検知をして、どのような方法で、誰に連絡するのか。）
6.運用設計（予防保守）
- セキュリティパッチ（windows update）の運用方法を決める。
- セキュリティ部門が重要と判断したパッチは即座に適用する。
- 重要でないパッチは3ヶ月に1回適用する。
- ハード障害の予兆が出た場合の対応方法を決める。
- 予兆が出たら即座に交換するのか。
- 重要な場所を定義し、重要な場所のみ予兆が出たら即座に交換するか。
7.運用設計（障害対応）
- 障害発生時のコミュニケーションチャネルを定義する。
- 障害情報をどこに保存し、どのように関係部門に共有するか。
- 障害情報の棚卸しを度のタイミングで実施するか。
↑ここまでが「構築を始める前に決めないといけないこと」
でも、ここがきっちり決まってたことは過去の経験上ないです。
なので、構築しながら決めていく必要がある＝「インフラ構築を行う人は設計スキルが必要」です。
決まっていない項目に対して、「自分の意見を作り、関係者に決めさせていく」
これがもっとも難しく、そして価値の有ることです。
8.インフラ構築
-
インフラ構築（サーバ、クラスタ、ストレージ、NW、DB、FW、監視）
-
インフラテストケース作成
- インフラ単体に障害を発生させ、設計通り切り替わることを確認する。
- アプリケーションも含めて、同様のテストを行い、アプリケーションの動作が想定通りになることを確認する。
-
インフラテスト実施
| テストカテゴリ | 構成 | テスト項目 | 期待値 | 確認結果 |
|---|---|---|---|---|
| Webサーバ | LoadBalance | アプリプロセスダウン | 監視が検知＆アプリエラーなし | ok |
| Webサーバ | LoadBalance | 再起動 | 監視が検知＆アプリエラーなし | ok |
| アプリサーバ | LoadBalance | アプリプロセスダウン | 監視が検知＆アプリエラーなし | ok |
| アプリサーバ | LoadBalance | 再起動 | 監視が検知＆アプリエラーなし | ok |
| DBサーバ | Active-Standby | DBプロセスダウン | 監視が検知＆failover＆アプリエラー確認＆リトライ確認 | ok |
| DBサーバ | Active-Standby | 再起動 | 監視が検知＆failover＆アプリエラー確認＆リトライ確認 | ok |
| NW | Active-Active | 電源オフ | 監視が検知＆アプリエラーなし | ok |
| NW | Active-Active | 再起動 | 監視が検知＆アプリエラーなし | ok |
- 重要性に応じて以下のようなテストを行うこともある
- ストレージからハードディスク抜いて問題ないことを確認
- サーバやNW機器からケーブルを抜いて問題ないことを確認
- 東証で問題となったようにメモリを抜くテストは聞いたことがない・・・。
- アプリチームへの引き渡し。
- 上記テストが終わってはじめてアプリチームへインフラを渡すことができる。
こっからは、システムリリース後の「システム運用チーム」の出番。
System Operations Team または、IT Operations Team。
私が会社で構築したチームは、「ITOPS（アイティーオプス）」と呼んでいて社内では一般用語になってる。
9.問題検知
- 「5.運用設計（問題検知）」に定義したように、問題を検知し、エスカレーションする。
- 加えて、エラーの回数が多く検知する必要がない場合は設定変更など、問題検知方法の改善を行う。
- エスカレーションした内容は記録しておき、改善に役立てる。（より効率よく検知できないか？）
10.予防保守
- 「6.運用設計（予防保守）」に定義したように、定期的なパッチ当て、もしくはセキュリティ部門の指摘による非定期的なパッチ当てを行う。
- また、ハード故障の予兆が出た場合には、決められたルールに従って交換作業を行う。
- これらの作業は記録しておき、改善に役立てる。（決めたルールを改善する必要があれば改善）
11.障害対応
- 「7.運用設計（障害対応）」に定義したように、障害対応をおこなう。
- 自分で行うものと、他のチーム（例：開発チーム、インフラチーム）に依頼することで分離を行い、他チームに依頼したものは進捗状況を管理する。
- 障害対応状況は随時、社内の関係者へ共有する。重大障害であれば経営層へ報告する。
- これらの作業は記録しておき、ナレッジとする。また、改善に役立てる。
- 障害対応は常に継続的に改善が必要。定期的に障害を棚卸しして、放置されている障害がないかや対応に問題があったかどうかの見直しなどを行う。
- 一度判断した結果は、明文化し、次に同様の障害が発生したときの判断に利用する。
（たとえば、経営層へ報告してシステムを止めると判断したケースでは、ルール化することで、同様障害時には経営層へ報告せずに対応ができるようにする）
Discussion