APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

一年ぶりに監視機能移行案件の振り替えりしてみた

はじめに

こんにちは、クラウド事業部の中嶋です。

今年の1月より現場が変わりばたばたしておりました・・・。

ふと落ち着いたときに過去にLT登壇した時の資料を眺めていたら、
丁度去年のこの時期に前の現場で取り組んだ案件を元に発表したスライドが出てきましたので、今回はそれを記事にしてみようと思います!
(´・ω・`).。oO(イマサラナンテイワナイデ)

当時行った案件は、JP1という既存の監視システムをAWSのサービスに移行するといったものでした。
IT未経験で初めての現場に配属され、4か月目に担当させて頂いた案件で当時の事を振り返りながら、今の自分の視点で見えることを記事にできればと思います!

読んでほしい方はこんな人!

今回の記事で扱う内容として、是非読んで頂きたい方は以下のような立場にいらっしゃる方と考えております!
⇒IT未経験で現場に参画された方
⇒AWSを扱っている方
⇒新卒の方
⇒経験が浅い方
⇒現場メンバーをマネジメントする方
⇒監視機能移行案件に携わっている方

私自身が冒頭にも記載した通り、IT業界に未経験で飛び込み右も左もわからない状態で、
案件一つを現場メンバーの力も借りながら完遂した時の体験になります。

ですので近しい立場になる、未経験で入社の方や新卒入社の方にはある種のしくじり先生のような感じで気軽に読んで頂ければと思います!
また、現場を管理される方には、経験の浅いメンバーが現場に配属された際、その方はどのようなことを考えているかをざっくり知ることができるかと思います。
技術面に関しても、イベント登壇に使用した資料を用いてわかりやすく説明できればと思っております。

案件の概要

今回の案件は、AWSサービスをメインで扱っている環境の監視機能(JP1)を移行するといったものでした。

↓のスライドが当時の既存環境です。 本来は冗長構成ですが、今回の資料は登壇用というこもあり、割愛しておりますのでご了承ください。

Nagiosサーバと各環境内のサーバにインストールされたnrpe(Nagiosエージェント)と通信を行い、
エラーログを拾って、そのログを「notification.log」ファイルに格納します。

「notification.log」ファイルに格納されたエラーログをJP1が拾い、
そのログをメール文に乗せる際に成形+エラーの種別を分けるために一意のIDを付与して所定のアドレスにメールを送付する。

といった構成になっておりました。
今回はJP1が担っていた4つの機能
・エラーログを拾う機能
・メール文の成形
・一意のIDを付与
・アラートメールの送信
をAWSサービスに置き換えるというものです。

実施内容

JP1からAWSサービスに移行した構成図が↑になります。
JP1の機能を、「Cloud Watch Logs」「Lambda」「S3」「SNS」の4つのサービスで補いました。

まず、Cloud Watch Logsを使用して、エラーログを収集します。
確かこの時(記憶が少しあいまいですが・・・)AWS Systems ManagerのRun Commandを実行してログ収集の設定を施しました。

そして、収集したエラーログをLambdaに引き渡すために、Cloud Watchのサブスクリプションフィルター機能を用いて、
エラーログ内の該当する文言をトリガーにLambdaに引き渡すように処理しました。

Lmbdaでは事前に作成したコードを用いて、引き受けたエラーログをメールに飛ばすにあたっての文章成型とメールに別途記載したい一意の文字列を付与します。

一意の文字列を付与するために、S3内にCSVファイルを格納しておきます。
CAVファイル内は、該当のエラーログと紐づけるために
「エラーログが吐き出されるパス」「エラーログ内の文章の一部(正規表現化)」「付与したい一意の文字列」を記載しておきます。

Lambdaの処理が走ったタイミングで、エラーログの成形+一意の文字列付与が行われ、それがSNSに引き渡されます。

SNSはそれを受け、事前に設定した所定のメールアドレスにエラーメールを発砲するといった流れになります。

細かい実装手順については、以下の記事を参照するほうがより丁寧に記載されておりますので、
気になった方は以下をご確認ください!

qiita.com

www.aws-room.com

qiita.com

dev.classmethod.jp

イベント登壇を通じて

以上のことを実施しまして、その時の体験・苦労話をイベントに登壇することでアウトプットしました。
参加したイベントがCloud Operator Daysといったイベントでして、イベント登壇と言っても
事前に撮影したプレゼンをYouTube上にアップして期間内に視聴できるといったものです!

なので、撮り直しができる点はとても気持ちが楽でした!
(ここだけの話リテイク3~4回くらいしましたw)

今後イベントに登壇してみたい!けど人前でいきなり話すのは。。。
といった方は事前撮影系のイベントがあればそこから経験値を積むのもありかもしれませんね!

ちなみに、その時のスライドと映像が以下になります!!

speakerdeck.com

33 IT未経験者が参画4ヶ月で既存監視JP1を廃止しAWSサービスに移行する知られざる戦いの全貌 - YouTubewww.youtube.com

イベントはオフラインで、クロージングイベントが行われまして、初めてこういったイベントに参加させていただきました!
社外の方と生の交流をする機会が滅多とないので、非常に刺激的でためになりました!

セッションやKeynote、近年スポットを浴びている技術(この時は生成AIでした)についてのDiscussion、交流会と盛りだくさんの内容でした。
今年もイベントが開催されるようですので気になった方は↓をご覧ください!

Cloud Operator Days Tokyo - Cloud Operator Days Tokyo 2024cloudopsdays.com

当時を振り返った所感

率直に1年たった内容のものでしたが、意外と覚えてました!
初めての案件ということもあるかとは思いますが、やはりアウトプットしたことで
より記憶の深部分に刻まれている感覚ですね。

今まったく同じタスクに取り組んで、登壇するとなったらもう少し技術的な観点を深堀したことが書けたりするのかなと思いますね。
当時はとにかくタスクを進めていくのに必死で、案件が終わった後はその経験を文字に起こすのに必死だったのでね。

今の現場ではAWSは触ってはいないのですが、やっぱりAWSいいですねw

今の現場は様々なサービス(伏せておきますが。。)を使用しているので、
画面の移動や切り替えの回数が以前より多くなりその分時間を要してしまっている感覚があります。
その点AWSだとその周辺サービスで完結するので、特に未経験や経験が浅い方が触れ始めるのに適しているのではないかなと思いました。

まとめ

ここまで御覧いただきありがとうございます!!
拙い記事でしたが、いい振り返りができました。

・どこかのタイミングでの振り返りは大事
⇒過去の自分の取り組みが自信になる

・アウトプットしたら記憶に残る
⇒より人に伝えるように準備するため咀嚼回数が増える

この記事が未経験や経験の浅い方・新卒の方の微力になれば幸いです。
また、管理職の方はそういった方を優しくサポートできる一つの着眼点になればと思います。

おまけ

過去にAWS資格取得を行いまして、この時の体験も記事にしております。
資格取得にご興味がございましたら、こちらも是非読んでみてください! また、その他の記事も掲載しておきます!

【過去記事のURL】

techblog.ap-com.co.jp

techblog.ap-com.co.jp

techblog.ap-com.co.jp


APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp

本記事の投稿者: 中嶋
AWSをメインにインフラ系のご支援を担当しています。