３ヵ月　新人インフラエンジニアが必要性を感じたインフラ知識の枠組み

【目次】

　①インフラエンジニアの役割

　②監視対象となる体系図（７つ）

　③監視対象における緊急度別の判断基準（４つ）

【内容】

初めまして。

この度、「ビヨンド・ブログ」に初投稿させていただく水沢喜裕と申します。

２０２０年８月からビヨンドのメンバーとして迎えていただきました。

現在は、徳島県三好市にある四国オフィスで。。。

いえ、大変失礼いたしました。。。

ペルシャ猫として大活躍中の井上さんと同じ場所である「ペル猫オフィス」で勤務させていただいております。。。お茄子も含めて、いつもお世話になっております。

なお、簡単ではこざいますが、私のこれまでの経歴につきましては、最後の「プロフィール欄」に記載いたしましたので、ご興味がございましたら、ご覧下さいませ。

さて、ここ最近は、なぜか「苔になりたい」、「苔になりたいよー」と本気で思い始めております。。。念のためですが、「海苔ではありません」、「苔ですよ」、「苔！」。

ここ大事です。テストには出ませんが、メチャクチャ大事です。

真面目な話。この思考に到達している背景には、ますます不確実性が高まっている世界を「内向的なタイプ」として生きてきた長い時間の中で、山口さんやSusan Cainさんの本との「最高の出会い」が関係しているのだと苔のように深く深く内省している今日この頃。。。が、そうしたお話しは、またの機会に。。。

というわけで、ここからが今回のブログの本題でございます。

初投稿の内容として、「体系的なITインフラの知識を把握すること」をテーマと位置づけました。各お題目としましては、「ソフトウェアエンジニアのための  ITインフラ監視　[実践] 入門  斎藤  祐一郎  著」という本を読んで学んだ知識の中で、未経験からキャリアチェンジした「新人インフラエンジニア」の私が、３ヶ月の実務を通して特に必要性を感じた点に焦点を当てた構成となっております。

そのため、現時点では設計構築側よりも、「運用保守側」の方向性を向いていることについて、ご容赦下さいませ。将来的には、「設計構築」の部分につきましても、ブログ記事にしたいと考えております。

なお、このテーマを選択した理由は、日々、インフラ業務の「内側」に触れる機会が多い一方で、「外側」の全体像を把握しきれていないことが、内側で発生している事象の理解を妨げていると実感することが何度もあったためです。

「料理」にたとえるなら、日々の自炊を通して、野菜炒めやハンバーグなどのスポット的な調理が少しずつできるようにはなってきているが、そもそも料理という外側の枠組みである「仕入れ、切り方、加熱、味付け、盛り付け」といった全体像を把握しきれていないことで、苦労してきた状況に似ているなと思っておりました。

そして、それを乗り換えるきっかけとなったのが「ロジカルクッキング」との出会い。具体的には、水島弘史シェフの本から「低温低速加熱＝1分で10℃上昇する弱火～弱い中火（野菜：max130℃、肉や魚：max180℃）」、「塩加減＝素材重量の0..8%」、「包丁の切り込み角度は30度」といった再現性の高い要素を把握できたことで、調理への負担が大幅に軽減した経験です。そして来月からは、その方法を自炊でなく、「ホットクック」と「ヘルシオ」といった調理家電で実現しようと考えております。

少し話はずれましたが、そういったプロセスをインフラエンジニアとしても、このタイミングで実施しておかないと、「非常にもったいない」と感じ始めた結果、この度、インフラ知識の「全体像」について振り返ってみることに決めた次第でございます。

特に、下記の皆様にお役に立てることができたらと思い、書き綴りました。

　①　インフラエンジニアを目指されている方

　②　入社数ヶ月の新人インフラエンジニア

　③　１年後の自分自身

それでは、まいりましょう。

インフラエンジニアの役割

　①インフラ設計

　　→お客様が期待されている性能を発揮するための要素を考慮に入れると同時に、

　　　「セキュリティ、冗長性、可用性、保守性、信頼性」といった障害が発生しにくい

　　　インフラ環境を構築するための要素も含めて綿密に設計する。

　②インフラ構築

　　→設計書に基づいた障害が発生しにくいインフラ環境を構築。

　③障害アラートの把握

　　→障害アラートをいち早く検知して把握することが非常に重要。

　　　弊社では、「Zabbix」や「Datadog」といったモニタリングツールを活用。

　　　そして、「５分以内」に一次返答する仕組みを構築しております。

　　→なぜスピードにこだわるのか。その理由は、新人研修後の実務で日々、痛感しております。

　　　具体的には、数秒の遅れがお客様のサービスに甚大な影響を及ぼすこと。

　　　見たいWebサイトにアクセスして数秒待たされる状況をイメージしていただくと、

　　　その影響度の深刻さを感じていただけると思います。

　　　そして、原因調査をする際も、数秒の遅れで「アクセスログ」などの障害発生箇所を

　　　特定するのに、そうでない場合と比較すると数倍の時間がかかることになります。

　④復旧対応

　　→弊社では、「障害が発生したときに1秒でも早く復旧までこぎつける」ための

　　　体制を整備しております。

　　　具体的には、「インフラエンジニア」が24時間365日、常駐できる体制を整え
　　　ながら継続的な改善を日々図っております。

　　　また、利害関係者様との円滑なコミュニケーションを図るために、「Chatwork」、

　　「Slack」、「Mozilla Thunderbird」といったコミュニケーションツールを活用しております。

 

監視対象の体系図（７つ）

　①  死活監視(サーバへのログイン状況)

　　→対象ホストに対してICMPレベルでのPing疎通の有無を監視する。

　②  ポートの死活監視（サーバへの動作状況）

　　→特定ポートへの疎通有無を監視する（80、443など）。

　　→topやpsコマンドで確認する。

　③  プロセスの死活監視

　　→特定プロセスの起動有無や起動数を監視する（Apache, MySQL, Zabbix-agentなど）。

　　（１）MySQL

　　　　　・接続数については、my.cnfの値を上限とする。

　　　　　・レプリケーション遅延については、スレーブサーバにのみ適用。

　　　　　　その理由は、マスタサーバからスレーブサーバへのデータ転送時に

　　　　　　おける遅延状況を監視するためのものだから。

　　　　　・innoDB Buffer Poolについては、事前にmysqltuner.jpを活用して

　　　　　　チューニングするか、必要に応じてインスタンスの物理メモリを増強することを検討。

　　→負荷が上昇しているプロセスを特定する。

　④  パフォーマンスの監視

　　→監視対象の「性能指標」を監視する。

　　（１）CPU Load Average

　　　　⇒CPUに対する平均の実行待ち状況。

　　　　　５秒毎に計算され、１分と５分と１５分の平均で表されます。

　　　　　具体的には、「top -c」コマンドで確認することができます。

　　（２）CPU idle

　　　　⇒CPUの空き状況。

　　（３）CPU iowait

　　　　⇒inputとoutput処理におけるCPUの待機時間。

　⑤  リソースの監視

　　→監視対象の「使用状況」を監視する。

　　（１）メモリ使用率

　　　　⇒合計容量が不足すると、Linuxにおいて「OOMKiller」が発動し、その時点で

　　　　　メモリを多く使用しているプロセスを強制終了してメモリを確保しようとします。

　　　　　その結果、強制終了の対象となるプロセスによっては、システム障害発生の可能性がある。

　　　　　具体的には、「free」コマンドで確認することができます。

　　（２）Swap使用率

　　　　⇒「Swap」とは、メインメモリが不足した時にメモリの中身を一時的にハードディスクに移すもの。

　　　　⇒スラッシング（Swap out/inが繰り返されること）

　　　　（a）「Swap out」とは、メインメモリの不足時に、使用されていないメモリページ

　　　　　　    領域からSwapメモリに移動し、メインメモリの空き容量を確保すること。

　　　　（b）「Swap in」とは、Swapメモリにあるメモリページが再び読み込まれること。

　　　　　　    なお、Swapメモリからの読み込みは、メインメモリからメモリページを読み込むよりも

　　　　　　    数万倍遅く、サーバ全体のパフォーマンスを著しく低下させる原因となりえる。

　　（３）disk使用率

　　　　⇒disk使用率が肥大化している場合、重要性の低い過去のログやbinaryファイルなどを削除する。

　　　　　また、ログローテーションの設定を行うことは、肥大化の予防につながります。

　⑥  外形の監視

　　→お客様のコンテンツである特定のWebページにアクセスできるかを監視。

　　　トップページは、実際にユーザーが行う動作と同じ状況からロードバランサを経由して監視。

　　→Pingの応答時間からWebサーバとの通信経路が途切れていないかどうかを監視。

　　→パケットロスが発生する場合は、通信速度の上限に達している。もしくは、

　　　ネットワーク機器の故障やネットワークのデバイスドライバに異常が出ている可能性がある。

　⑦  情報取得

　　→監視対象の情報を取得する。

　　（１）「システムのホスト名」の値が変更されたら通知する。

　　（２）「unameコマンド」の結果の値が変更されたら通知する。

　　（３）「/etc/passwdファイルのチェックサム」の値が変更されたら通知する。

監視対象における緊急度別の判断基準（４つ）

　①  Aランク

　　⇒サービス停止の可能性があるため最優先で対応が必要なもの。

　　（a）死活監視におけるアラート発生

　　（b）ポートの死活監視におけるアラート発生

　　（c）外形監視におけるアラート発生（お客様の特定Webサイト）

　　（d）プロセスの死活監視におけるアラート発生（Apache）

　　（e）プロセスの死活監視におけるアラート発生（MySQL）

　②  Bランク

　　⇒放置するとサービス停止の可能性があるため優先的に対応が必要なもの。

　　（a）CPU Load Averageのアラート発生

　　（b）CPU idleのアラート発生

　　（c）CPU iowaitのアラート発生

　　（d）メモリ使用率のアラート発生

　　（e）プロセスの死活監視におけるアラート発生（Zabbix-agent）

　③  Cランク

　　⇒即座にサービスの影響は発生しないが、可能な限り迅速な対応が必要なもの。

　　（a）Swap使用率のアラート発生

　　（b）disk使用率のアラート発生

　④  Iランク

　　⇒情報通知のみ。発生原因の調査を実施するもの。

　　（a）「システムのホスト名」の変更通知。

　　（b）「unameコマンド」の結果変更の通知。

　　（c）「/etc/passwdファイルのチェックサム」の変更通知。

まとめ

いかがでしたでしょうか。
インフラ業務の全体像を把握するためのお役に立てたでしょうか。

私自身、２０２０年８月からインフラエンジニアの業務に初めて携わってからというもの、この仕事がお客様の大切な「情報資産」をお支えできる意義ある仕事であることを実感しております。

ただ、その一方で、緊張感と危機感を日々抱きながら、壁にぶつかり続ける日々を過ごしております。正直、３ヵ月でどれだけ登れているのかは分かりませんが、これからも今できることを日々もがきながら１つずつ増やしていくしかないなと思っています。

幸い、自分で仮説を立てて考えた上で、ご質問すれば、ご相談にのって下さる方々に恵まれているので非常に感謝しております。

その過程で、これからもインフラエンジニアとして利害関係者の皆様にお役に立てられるように精進していきたいです。

既に長文になっていて恐縮ですが、最後に、やっぱり、「内向的なタイプ」としてのお話しもさせて下さい。すみません。。。

その理由は、「インフラエンジニア」という職業が、もしかしたら、「内向的なタイプ」の人が馴染むことができる環境の１つかもしれないと感じ始めているからです。

現在、私は「内向的なタイプ」という性格を自然と受け入れて育んでいけるフェーズにおります。でも、２９歳までは全くそうは思えず、自分を否定する日々が続いておりました。

それらを受け入れられたのは、それ相応の機会に恵まれたからなのですが、自分の中では非常に厳しい道のりでした。。。

だからこそ、インフラエンジニアとして仕事に関わる過程を通して、「内向的なタイプ」の方々にとっても、お役に立てることができれば個人的には非常に嬉しいです。

これから長い道のりになると思いますが、「苔」のように長い目で見ていただけると幸いです。どうぞよろしくお願いいたします。