Service Engineering Division / DevOps Unitの出口です
先日,社内勉強会にて「EIPプールをつくったお話」をユニットの代表として発表させていただきました. 発表内容のダイジェストをこちらのHDEブログに書いて欲しいという依頼を頂きましたので 僭越ながらありがたく書かせていただきます.
DevOpsチームにとってのEIP
メールサービスをお客様へ提供するために リリース作業のなかで新しいEIPを取得し,お客様のテナントと紐付けを行っています
しかしながらただEIPを取得するだけではなく以下の作業(設定の申請)を行わなければなりません
- メール送信制限の解除申請
- IPの逆引き申請
- RBLの解除申請
「なんだたったの3作業か,それぐらい仕事しろよ」と思われるかもしれませんが 実際に作業をしていると以下の問題点が浮上します
AWS作業遅れがリリース作業スケジュールに影響を与えている
AWSの作業遅れによりリリース作業を行うときに時間に余裕を持たせなければいけなくなります確認作業を行う必要がある
RBL解除されているかの確認作業を行う必要があります生身の人間がEIPを操作するのには無理がある
現状EIPにはタグ等を付けられないので XXX.XXX.XXX.XXXのEIPの申請を間違えてYYY.YYY.YYY.YYYで出してしまった等のミスが考えられます
ということでEIPを貯めておくプールを作りました
これらの問題を一挙に解決するためにDevOpsユニットが頑張ってEIPを蓄えておけるプールを作りました. 簡単なフローは以下のとおりです
- 定期的にEIPを「申請解除待ち」状態としてためる
- 自動的に申請を出す
- 別タスクで定期的にRBL等から解除されているか確認をする
- 解除されたことが確認されたら「申請解除」状態にする
また上記フローとは別に以下の機能もつけました (詳しい説明は割愛)
- ログを残す (基本中の基本)
- Slack通知機能
- RBL監視システム
EIP Poolが実装されたよ
そして先日,ついに本番環境へ実装されました
朝のMTG後にJenkinsさんがEIPプールの状態をお知らせする様子がこちらです
現在DevOpsユニットでは最大30のEIPを確保するような設定になっているのですが, 上の図は自由に使える状態(つまり申請が処理されて設定済み)のEIP(緑りんご)が24あり, 申請が処理されるのを待っているEIP(赤りんごとなす)が4つあり, 空いている状態(ふたば)が2つとなっています(こちらの空きは自動的に補填されるようになっています)
ここで地味に注目していただきたいのが「なす」です
この「なす」のマークが付いているEIPは申請は出したけれどなぜか長期(7日以上)経過しても
設定されていないEIPに対してつけられるマークで以前までの環境だと
リリース遅延の原因となりうるEIPだったことを意味します
一方でEIPプールを実装した後はすでに確保してある設定済みのEIPを使えば良いため, このようにリリース遅延の原因をなくすことが出来ました.
おわりに
今回ご紹介したEIPプールは自動化に関するほんの一例で DevOpsユニットではEIPプールにとどまらずさらなる自動化やリリース作業の効率化によって日々進化をしつづけています
機会があれば,皆様にDevOpsユニットがどのようにして効率化をしているかご紹介できればと思います. つたない文章でしたが最後まで見て下さりありがとうございます
