😈

NATGWを導入したことによるインフラエンジニアの幸福度と初のサービス停止を伴うメンテナンス実施について

2022/03/18に公開

インフラ

こんにちは。株式会社ペライチ のインフラエンジニア西野です。

今回は2021/3月末に弊社として初のサービス停止を伴うメンテナンスの NATGW 導入について振り返りを記事にしました。
その中で導入したことによるインフラエンジニアの幸福度と、初のサービス停止を伴うメンテナンスについても記載したいと思います。
最後までお付き合いいただけると幸いです。

そもそもNATGWって何?

まず、最初にNATGWとは何かについて簡単に説明したいと思います。
すでに知ってるという方はそのまま飛ばしてお読みいただければと思います。
NATGWとはネットワークアドレス変換サービスです。インターネットに接続できないプライベートサブネットに配置したインスタンス(アプリケーションサーバー等)がNATGWを経由することでインターネットに安全に出れるようする為のサービスとなっています。

導入経緯

今、使ってる EIP どれ? 許可申請したっけ?

弊社では AWS を導入しており、これまでアプリケーションサーバには EIP を持たせグローバル環境へ配置をしていました。
アプリケーションサーバーは外部ツールと連携している部分もあり、外部ツール側で IP 制限をかけている場合、スケールアップの度に EIP の許可申請を出していましたが「申請忘れてました…」や「あれ?今ってどの IP 許可されてるんだっけ?」など本番環境としては致命的な問題がありました。
「いい加減 IP 管理と申請が面倒なんですけど!」と言うわけで、 NATGW を導入して煩わしさを軽減しよう! となりました。
それに、併せて弊社ではこれまでサービス停止を伴う作業の事例がなかった為、ついでにサービス停止を伴うメンテナンス作業の標準化もやっちゃおう!と言う、ノリと勢いでNATGW 導入の決まった経緯があります。

NATGW設置にあたってのやることの整理


各環境によって新規作成等のやることを整理して洗い出しておくことで、メンテナンス前にやっておくべきこと、メンテナンス当日にやるべきことが明確になります。
下記には NATGW を設置するにあたって必須な作業を2つ記述します。

プライベートサブネットの作成
  • Multi-AZ(冗長構成)で作成しました。
  • 弊社はインスタンスやRDSはここに設置しました。
NATGW の作成
  • Multi-AZ(冗長構成)で立てています。
  • NATGWはプライベートではなく、グローバルサブネットに配置します。
  • ルートテーブルの作成もお忘れなく、 NATGW を通る経路を入れる必要があります。

さぁ、いざ出陣!

さて、実際どのようにメンテナンスを実施したのか軽く説明しておきます。
上記に記載のある、やることの整理でメンテナンス前にやっておけること、メンテナンス当日にやらなければいけなことが明確になり、当日作業がスムーズに出来ました。

  1. ALB の固定レスポンスの機能を使ってメンテナンス画面を表示
  • 複数機能分の ALB が存在するので、全ての ALB に対して同様の作業をします。
  1. RDS のバックアップ
  • メンテナンス画面の停止以降は DB への書き込みがなくなるので、そのタイミングで
    RDS のバックアップを開始します。これは手動ではなくバッチを作って自動で行います。
  1. バッチの停止
  • メンテナンス時間に稼働しているバッチを停止しておきます。
  1. EC2(アプリケーションサーバー)の切り替え
  • ALB のターゲットグループで EC2 の入れ替えを行います。
  1. サービスの正常性確認
  • 切り替え完了後にサービスの正常性確認をします。機能が複数あるため、ここが一番大変でした。
  1. メンテナス画面の解除
  • ここまで来ると、ゴールテープが見えてきた感がしました。
  1. 開局後の停止バッチの再稼働
  • 停止したバッチを再稼働して、正常終了を見届けて Finish です!

書いてみると、意外にもメンテナンス自体は大変な感じがしないですね。

やってみて実際のところどうだったのか


NATGW設置後は、IP管理の呪縛から解かれた
NATGW 設置によるスケールアウト発生時の IP 申請が不要になったこと、そもそも使っている EIP の管理の呪縛から解かれたとことは非常に幸福度が高いです。
弊社ではアプリケーションサーバーだけで20以上のEIPを管理していたものが不要になったこと、外部サービスへの IP 許可の申請が不要になったことは煩わしさがなくなりました。

サービス停止を伴うメンテナンスの成功の鍵

サービス停止や構成が大きく変わるメンテナンス成功の鍵は綿密な準備と部署横断の協力
事前の準備はもちろん、今回のメンテナンスで特に感じたことは、インフラチームの以外のアプリ開発チームやカスタマーハピネスチームなど部署を横断して快く協力してもらえたことが成功に繋がったのではないかと思います。
メンテナンスが無事に終わり、オフィスに日差しが差し込んだときの高揚感は忘れることがないでしょう。
インフラエンジニアの仕事は、中々ユーザーに直結する機会も少なく、周りからも何やってるんだろうと思われがちですが、裏では責任重大な仕事をしているんだな〜ということが少しでも理解してもらえると救われますね。
弊社では、部署の壁がなく横断して協力してくれるため、難易度の高い作業でもトライしやすい環境が整っています。是非、話してみたいという方は下記の採用情報をご覧下さい。

以上、簡単ではございますが、私のテックブログとなります。
本記事が、これから NATGW を導入しようと検討している方、また会社としてサービス停止を伴うメンテナンスを控えている方の参考になれば幸いです。

採用情報

現在エンジニア募集しています!

▼ 選考をご希望の方はこちら(募集職種一覧)。
https://hrmos.co/pages/peraichi/jobs?category=1629135637016141824&utm_source=techblog&utm_medium=referral&utm_campaign=article-01fy5mgvh33ev789jfsewrngkg

▼ まずはカジュアル面談をご希望の方はこちら
https://hrmos.co/pages/peraichi/jobs/0000029?utm_source=techblog&utm_medium=referral&utm_campaign=article-01fy5mgvh33ev789jfsewrngkg

募集中の職種についてご興味がある方は、お気軽にお申し込みください(CTO がお会いします)

ペライチ

Discussion