YAPC::Asia Tokyo 2015に参加しました

こんにちは、クラウドプロダクト開発部の篠原です。

20-22日にYAPC::Asia Tokyo 2015が開催されました。同僚に主催者の牧さんがいたり弊社もスポンサードしていたりという縁もあり、初めてYAPCに参加してきました。 （HDEがスポンサードするようになった経緯はこちら: HDE Inc x YAPC::Asia Tokyo 2015 - HDE BLOG）

YAPCの興奮が冷めないまま週が明け出社したところ、突然向かいの席にいる牧さんから

ブログ書くまでがYAPC！！！

— Daisuke Maki (@lestrrat) August 22, 2015

と言われてしまったため、わたしもブログを書くことにしました。

Perl Conference?

YAPCは「Yet Another Perl Conference」の略で、Perlのカンファレンス…ではありません。 YAPCでは、Perlに限らずGolangやJavaScriptなどPerl以外のプログラミング言語のトークからリモートワークやエンジニアとしての姿勢など働き方のトークまで、多種多様なトークが発表されました。わたしは普段はJavaScriptやGolangを使っているので、YAPCは今までPerlのカンファレンスと思ってスルーしていました。完全に騙されました。

Comment about Talks

YAPCのトーク一覧とスライドは、公式ページのTalksで確認できます。感想などは、公式ページの感想エントリまとめや、Togetterで確認できます。ためになるトークばかりだったので、ぜひご覧ください！折角なので、個人的に印象に残ったトークをさくっとご紹介します。

我々にできるOSSとそのコミュニティの育てかた - @tagomoris

How to create/improve OSS products and its community from SATOSHI TAGOMORI

www.slideshare.net

Treasure Dataの@tagomorisさんの発表です。OSSを公開する理由からOSSをどうやって育てていくかとい発表でした。弊社も過去にOSSを公開して苦労したので、発表の間は頻繁に共感していました。発表の中で印象的だったのが「IssueやPullRequestは常に英語を使う。日本語のPullRequestは即却下」といった英語の重要性です。弊社は会社の共通言語として英語を採用予定で、現在進行形で英語に激しく苦労しているため、激しく同意せざるを得ませんでした。

Effective ES6 - @teppeis

Effective ES6 from teppeis

www.slideshare.net

Cybozuの@teppeisさんの発表です。先々月仕様が公開されたECMAScript6についての発表でした。わたしは普段フロントエンドエンジニア的な仕事をすることが多いので興味津々でした。内容は、ES6の仕様をかいつまんだわかりやすい説明でした。ES6の仕様は、Pythonなど他の言語と似た仕様が多く、使いやすそうで学習コストも少なそうという印象を持ちました。これからはES6の時代ですね。また、ES6からES5のコードを生成するTranspilerであるBabelを紹介されていました。「これからはバベっていこう」がキーワードでした。バベっていきましょう。

YAPC::Asia Tokyo 2016?

以上ですが、簡単なトークの紹介でした。

とてもためになったので来年もYAPCに参加するぞ！と意気込んでいたのですが、なんとYAPC::Asiaは今年で最後らしいです。まさか初参加で最後とは…。YAPCのように垣根のない多種多様なカンファレンスは貴重なのでかなり名残惜しいです。が、つぎはPerlという冠がないカンファレンスが開催されるとかされないとかいう噂が！？楽しみです！

最後になりましたが、YAPCの運営スタッフの皆様、お疲れ様でした！

GopherCon 2015に参加してきました

クラウドプロダクト開発部たなべです。

去る2015年7月にアメリカはコロラド州デンバーで開催されたGopherCon 2015に参加してきました。 アメリカ出張は昨年のDockerConに続いて2度目です。

デンバーはみんな大好きサンフランシスコから約1900km離れています。Google Mapによれば車で18時間だそうです。飛行機なら2時間ですので西海岸からのアクセスも良好と言えそうです。昨年からは成田空港、デンバー国際空港間で直行便の運行が始まり便利になったそうです。

今回はエクストリーム和装家としても有名なCTOと一緒に行きました。

上の記事でも触れられていますが、滞在期間中のデンバーはあまりパっとしない天気で、どちらかといえば日中もすこし肌寒い気温でした。

GopherCon二日目は晴れ間が見えましたが、滞在中は雨が降ったり止んだりと不安定な天候でした。

会場となったのは上の地図で上げたコロラドコンベンションセンターです。コロラド州といえばロッキー山脈などの大自然です。

(熊もGopherConに興味津々の図)

会場前にはCoreOSトラック（バス？キャンピングガー的なもの？）が止っていました。ひょっとしてCoreOSチームはこれに乗って1900kmもはるばる来たんでしょうか…？

まずGopherConで驚いたのは参加者に配られるグッズの豪華さでした。

ただのリュックではありません。参加者がほぼ開発者であることを見越して、きちんとラップトップ収納用スペースがあり、バッテリーやケーブルなどの細かいものもきちんと入れられるものでした。

ロゴ入りのコップです。アメリカンな大きさですが、この季節、麦茶をめいっぱい入れて飲むのに使っています。お気に入りです。

他にもスポンサー提供のグッズがリュックに大量に入っていました。

GopherCon 2015のメインセッションはシングルトラックで二日間で計22セッションが行なわれました。そのためセッションは朝から夕方までびっしり入っています。

朝7時すぎから朝食が用意されました。

コーヒー、甘いもの、そしてオートミール。メニューは両日とも同じでした。

Wikipediaを読むと健康食として人気のようです。ただ、見た目がアレでCTO曰く、日本人でちゃんと食べたのは私が初めてとのことです。シュガーやドライフルーツを入れればおいしく食べられました。

13時から昼食でしたが、ビュッフェスタイルにも関わらずパイプラインが4本程度しかなくスループットがまったく出ていませんでした。そのため会場の外に人が溢れ返っていました(Goのカンファレンスなのに!!)。そしてお昼の写真は取り忘れました…。

朝食と昼食は見知らぬ人との絶好の会話の機会です。どういう仕事をしているのか、どういう技術スタックを使っているのか、どこで苦労しているのかなどを情報交換できるのがカンファレンスのもう1つの目的です。今回は英語が話せるCTOもいたため興味深いGoのユースケースを聞くことができました(そして大抵そういう話は書けない)。

ホール外にはスポンサーブースがありました。今回はCoreOSのetcd Tシャツをゲットしました。

いくつかのセッションについて触れたいと思います。すべてのセッションのスライドと動画は http://blog.golang.org/gophercon2015 から辿れます。

• A Practical Guide to Preventing Deadlocks and Leaks in Go Comcast(大手ケーブルテレビ会社)でのGo in Productionから学びについてのセッションでした。
• Go For Mobile Devices gomobileチームによるGo Mobileの現状についてのセッションでした。今後かなり盛り上がる分野だと思います。
• Rebuilding Parse.com in Go - an opinionated rewrite ParseのGoへの移行話です。Blog記事の反響の大きさも記憶に新しいところです。

動画では省略されていますが、MCはCoreOSのKelsey Hightower氏でした。

• Betting the Company on Go and Winning

ベテラン司会者を彷彿とさせる軽快なトークとジョーク（みんな笑ってるけど英語がまったく聞き取れず笑えなかった）で笑いを量産していました。いよいよ今月となったYAPC Asiaでのトークがとても楽しみです(同時翻訳付き!!)。

Go teamからはオープンソースコミュニティとしてGoについてのトークがキーノートそしてクロージングで行なわれました。

• Go, Open Source, Community — Russ Cox
• How Go Was Made — Andrew Gerrand

Goはもともと数名の少数チームで言語デザインを行なってきました。初期にはこれらはうまく行きましたが、Goのエコシステムが拡大するにつれコミュニティと協力してこれらのGoを作っていくことが重要という趣旨をGo teamが繰り返し話していたのが印象的でした。

• vendoringについて: 従来Googleでは問題ではなかったとの姿勢だったのが『Goコミュニティは「問題」として認識していること』を認識し、Do Less, Enable Moreに基いてGo 1.5に実験的機能(GO15VENDOREXPERIMENT)を入れ、よりよいベンダリングのための仕組みを設計していく
• Code Of Conductついて: コミュニティを形成していくにあたりCode Of Conductの必要性があるのではないかという発議
• デザインプロセスの明文化: 提案の仕方、提案の評価、提案の履歴などを残せるように仕組みを用意していく

次の5年(10周年)に向けての足固め的セッションだと感じました。私も影ながら見守っていきたいです。

そして、英語

こうして海外のカンファレンスに行けるのはこのブログでも何度も触れているように英語の社内公用語化を来年に控えているためです(つい最近コピー機の言語設定が英語になりました)。

CTOは帰国子女で私から見ればペラペラです。しかしそれでもセッション後の質疑応答の聞き取りには苦労したそうです。無論、私はまったく聞き取れませんでした。

日本国内にいてそれなりに日本人の話す英語、アジア人が話す英語が聞き取れるようになった私ですが、やはりネイティブが話す英語を聞き取るにはまだまだ訓練が必要（そして私にとっての今の壁）であることを再認識したアメリカ出張でした。

ともあれ、言語習得に近道はなさそうですから、来年はもうちょっと成長して海外出張に行けるようまた1年がんばりたいと思います！！

労いの肉！の図(ごちそうさまでした!!!!)

OSCON 2015に参加してきました

OSCON 2015に参加してきました。実はOSCONは初参加です。

場所はオレゴン州ポートランド。アメリカ北西部の町です。着いた週末は熱波に襲われていたようで地元の人達は暑さにあえいでいたようですが、東京から来た自分は「湿気がないだけでずいぶん過ごしやすいな」程度の感想でした。滞在中は天気にも恵まれ、大変過ごしやすかったです。反面熱波が落ち着いてくると、夜はかなりひんやりした感じでした。

一般客のチェックインはセルフサービスだったようです。私はスピーカー枠だったので別部屋でした。OSCONで少し印象的だったのは、かなり明らかに参加者の中にヒエラルキーのようなものがあり、一般参加者、スピーカー、スポンサー、とかなり提供されるサービスに差があったということです。仕組み的には当然だとは思うのですが草の根活動的なカンファレンスばかり主催していたので印象に残りました。

最初の二日間はチュートリアル等がメインです。チュートリアルは一枠3時間のものと6時間のものとあり、かなりガッツリ行われている印象です。自分は諸事情によりほとんどこれらには参加していませんが、ミーティング等の間にMesosのチュートリアルに参加してみたりしました。

ハンズオンセッションだったのですが、講師の方々はプロのエンジニアですがプロのチュートリアル講師ではないので進行に若干不満が残りました。内容はなかなかおもしろいものでした。ちなみにほんの一昔前までは聴講者にチュートリアル用の環境を用意するのはなかなか大変な事でしたが、今は「Vagrantを入れておいて」程度の周知をした上で6GBくらいのイメージを渡せばそれで済むのですからバーチャリゼーションやコンテナ技術に感謝感謝といったところです。

聴講している以外の時間は主に来場者達と色々な話をするか、自分のスライドの準備に費やしていました。去年日本で会ったDave Cheney氏や今年のYAPC::Asia Tokyo 2015で来日予定のCasey West氏とKelsey Hightower氏にも会うことができました。

会期中はずっと昼食が提供されていました。かなり広めのホールにテーブルがずらりと並べられ、プレートをもらってセルフサーブで盛ったご飯をテーブルでいただく感じです。

自由に情報を貼り付ける事ができるボードがあり、ここで求人や求職活動が行われていました。こういうオープンな活動はもっと日本でもやれればいいのになーとは思うのですが、やはり文化の違いですね。

なおその横にはBoFの集まりを知らせるスケジュールもありました。こちらも空いている時間に自分で企画した集まりを告知して参加者を募ることができます。

こんな落書きスペースもあります。

二日目はOSCONタイミングを合わせてkubernetes 1.0 のリリースを記念したkuberconが開催されていたのでそちらも覗いてきました。やはりみんな気になるようでかなり盛況でした。

チュートリアルの最終日夜には「Ignite」という名称のLightning Talkです。このセッションではスライドは20枚のみで15秒ごとに強制的に切り替わり、確実に5分で話は終わります。運営側の無駄に時間を長引かせないための努力が見られる形式でした。

なお発表者の女性率の高さが印象的でした。これが「印象的」となってしまう事実はカンファレンス運営者としては反省しなくてはいけないですね。

三日目からキーノートと一般セッションが始まります。朝一番のブロックのキーノートではPaul Fenwick氏とAllison Randall氏のトークがなかなか印象に残りました。どちらも動画が提供されています

They're Here. What Now? - Allison Randal Keynote ...

The Future is Awesome - Paul Fenwick Keynote ...

セッションは12トラックもあるのですが、その合間合間には様々な企画が催されています。

Expo Hallではいわゆる展示会的な催しがあり、時間によっては軽食も振る舞われていました。

www.oscon.com

自分のトークはこれまで自分がYAPC::Asia Tokyo等で発表してきた物の英語版だったのですが、今回参加してみてこのチョイスは若干ミスだったと思っています。

OSCONは良くも悪くもすでに一大展覧会であり、オープンソースの意義や啓蒙についてのイベントです。現場エンジニアのレベルの話より業界を変えていく話だったり、業界全体の技術トレンド等について興味がある人が集まるということです。その中で技術そのもの、しかも言語間の根源的なトピックについて話すのは微妙だったな、というのが正直な感想です。次回参加する場合はそのあたりを踏まえ、もう少し上のレイヤーの話を用意して行こうと思います。

www.oscon.com

イベントの楽しみ方としてはやはりトークそのものよりトーク前後に関係者を捕まえて四方山話をするほうが遙かにためになりそうでした。トークの内容に関しては技術的に細かい話はそれほど多くないので、トレンドを読み解くという意味ではスケジュールを見れば見えてくるものがあるのでそれで事足ります。さらに突っ込んだ話はパーティーやレセプション、そして廊下での会話の中でしか得られないという気がします。

ちなみに今回のテーマは明らかに"Cloud Native Applications"とKubernetes, Mesos, Docker等を用いたマイクロサービスアーキテクチャだったと思います。正直に言うと業界トレンドとしてはそうなのだと思いますが、現場でコードを書いている身からするとわりと今更感があったので、それを五日間繰り返し繰り返し連呼されるのは最後にはおなかいっぱいという感じでした。

おまけ

ポートランドダウンタウンのKenny and Zuke's のルーベンサンドイッチが超絶うまかったです。

あと偶然会場までの経路にベトナム人街があったので、会場以外でご飯を食べるときはそこでフォーを食べていました。日本のフォーもおいしいのですが洗練されすぎててなかなか納得がいかないので、アメリカで手に入るフォーが大好きなのです…

というわけで色々楽しいポートランド滞在でした！

English as a Second Presentation Language という取り組みを始めてみました

HDEでは近いうちに公用語が英語に切り替わるということもあり、月一のテクニカルセッションは英語だったり、ミーティング等も英語だったりします。そのようなわけで英語に触れる機会はそれなりに多いのですが、やはり議論や質問をする場があったほうがいいなぁと思い新しい取り組みを始めてみました。

アメリカンスクールに通う子供で英語を（十分に）しゃべれない子供はESL (English as a Second Language)というカリキュラムに入れられてまず英語を重点的に勉強させられるのですが、それにひっかけて "English as a Second Presentation Language"として、プレゼンを通して英語の疑問をぶつけたりそれに答えたりする企画です。これまでもいくつか英語でプレゼンをする集まりはあったと思うのですが、具体的な質問をしたりプレゼンに対してのフィードバックをする時間を設けよう、というのが趣旨です。ちなみに私は小6の時に海外に引っ越しした際にアメリカンスクールにぶち込まれ、ESLに1年間在籍した経験があります。

今回は初回ということでまず私がどういうことを気をつけるべきかを含めた話をさせてもらったあと、社内から次のテクニカルセッションで登壇する予定の二人から練習をする形で発表をしてもらいました。

私の発表は以下に置いてあります。読まれる場合はスピーカーノートを開きながら読んでいただくとよいかもしれません（プレゼンテーション表示中に"s"を押してください）。

いくつかのポイントとしては

• 英語の細かい規則にこだわるより観客に伝えることを考えよう
• 得意でない言語でプレゼンをするなら、プレゼンの基本的なテクニックをより意識しよう
• 具体的なtipsをいくつか

というようなことについて語らせていただきました。

プレゼンテーションのあとは質問タイムで、20〜30分ほど質問を最初は英語その後日本語で受け付けて答えたりしました。この英語で質問をする、というのが意外と重要なのでこれをもっと推していけるような仕組みを作るべきと感じました。もちろん日本語でも良いんですが…

その後は社内の二人からの発表。本来はこちらのほうがメインのコンテンツです。発表がおわり、これまた10分〜20分ほどのディスカッション時間を設けました。発表者と聴講者両方からの質問がありました。ディスカッションの内容は発表の内容、言い回し、時制についての注意等が出ていました。

なお本番は1週間後ということもあり、まだ準備中のスライドでしたが、だからこそこのタイミングで英語やプレゼンの構成をみんなでディスカッションする意義があると個人的には思っています。

今回は初めての回ということでとりあえずどうなるか見るために徒手空拳で開催してみました。主催側からの次回の改善点としては

• もう少し発表者・聴講者から質問等を出しやすい（強制的に出す？）フォーマットを作る
• ディスカッションに参加しやすいように事前準備をする
• なんとかして英語で質問をしてもらう

というような事を考えました。ともあれ、第一回としてはなかなか良い感じだったと思います。

うまく回るようになればもっと一般から参加者を募って開催したいと考えていますので、もしこのような企画に興味がある場合は是非私（@lestrrat）のほうまで連絡ください！

はじめての障害演習

どうもこんにちは。 Account Management Section の服部／安孫子がお送りします。

みなさんは自社が提供しているサービスに障害が起きた場合の備えは万全ですか？ 特に大規模な障害が起きてしまった場合、構築している体制で迅速な対応ができますか？

今回は、弊社内で実施した HDE Oneサービスの障害対応演習について企画者の一人として書いてみたいと思います。

演習実施に至った背景

過去に発生したHDE One サービスにおける障害発生を機に、再発防止のシステム改善と強化だけではなく、社内オペレーションの見直しと障害のケーススタディを行い、対応の練度をあげる必要性が社内で議論されていました。

また、障害発生後にご契約いただいているお客様を対象としたアンケート結果からも、「情報公開」「連絡頻度」「対応スピード」について多くのご意見をいただきました。 そこで社内にプロジェクトチームを立ち上げ、取り組みの第一弾として障害対応演習を実施することになりました。

目的の再確認

第一回である今回は、演習用のクラウド環境などは準備せず、障害発生時の人のオペレーションと課題抽出、コミュニケーション強化をテーマとしました。 訓練も机上演習ながら長い時間を使って演習を行う都合上、週末に実施することに決定しました。

初期の議論のホワイトボード

企画：真面目さと遊びココロのバランス

目的はきっとメンバーにも理解してもらえるでしょう。

でもお題目として理解してもらっても意味はない。

参加メンバー全員が当事者意識と危機感をもって参加してくれなければ、わざわざ週末にまで出社して演習をやることはないと考えていました。 そこで、まじめにやる部分と楽しんでもらう部分のバランスに心を砕きました。

大まかな構成は以下の３部構成。 ①レクリエーション ②ディスカッション ③障害演習

実は、一番早くディテイルが決まったのが①の部分です。内容は「人狼村からの脱出」というリアル脱出ゲームを開催しました。

障害対応のポイントは何度も議論を尽くしたのですが、対応のリーダーシップと役割分担、社内での円滑なコミュニケーションなどのポイントが上がりました。 このゲームは挙がってきたポイントをほぼ全て押さえられるものと判断し、企画のメンバーでテストプレイをしてみて実施を決定しました。

以下、演習当日のハイライトをお送りします。

実際の演習の様子

演習開始：

午前の部：チームビルディング(人狼村からの脱出)

実際のプレイでは、写真のように準備された資料を解いていく事で人狼を突き止め、人狼村から脱出することがゴールです。

午前の部：ディスカッション 過去の経験から改めて障害対応で何が大切になるのか、各メンバーから意見を出してもらい、発表してもらいました。

午後の部：障害演習

プロジェクトチームが用意したケーススタディを元に、4チームに分かれて割り振られた障害に対しに最適な行動を決定し、質疑応答のなかでさらに議論を深めていきました。

刻一刻と変化していく状況にどう対応すべきか議論していく中で、チームが取り組んでいくべき課題がいくつも見つかったことが大きな成果でした。

想定した障害の中には HDE One サービス全体がそもそもダウンしたらどうするか、障害発生時の状況の中には対応すべきメンバーが全員対応不能な状況になっているなど想像するのも恐ろしいものも含まれていました。

午後の部：ディスカッション

第一回の演習で得た気付きは以下の通りです。
- 障害とは何か、障害対応とは何か、当事者間での意識統一の重要性

- 迅速かつ確実な対応を両立させる体制構築の重要性

- 演習の定期実施の必要性

- 社内全体を巻き込んだ情報共有や訓練実施の検討

メンバー全員が高い当事者意識を持ち、お客様に満足いただけるサービスとは何か、という点を真剣に議論する姿が印象的でした。 今後の演習ではクラウド上構築した演習環境を使っての演習実施を計画しています。

最後は打ち上げ、みなさんお疲れ様でした！

偶然にもこの日は、我らがセクションのボスでもある副社長宮本がもうすぐ誕生日でしたのでお祝いをしました！

ボスとケーキ：

HDE では弊社サービスを安心してご利用いただけるよう、チーム一丸となってお客様をサポートして参ります。今後も弊社の取り組みを本ブログにて皆様に公開して参りますので何卒宜しくお願いします。

以上です。

PandoraFMS を使ってみた

System Consulting & Sales Division の荒川です

先日、社内勉強会にて「PandoraFMS」を発表させていただきました。 発表内容のダイジェストをこちらのHDEブログに書いて欲しいという依頼を頂きましたので ありがたく書かせていただきます。

pandoraFMS とは？

PandoraFMS とは、スペインで開発されているオープンソースの監視ツールになります。 オープンソースの監視ツールとしては、Naigos や Cacti 、 Zabbix などが有名ですが、 PandoraFMS はどちらかというとマイナーな部類になると思います。

（結構知られていると思ったのですが、社内勉強会では、「どこで見つけてきたの？」 的な質問が多く寄せられたので、マイナーな部類だと感じました）

また、PandoraFMS はエンタープライズ版（有償）もあり、こちらは使える機能が増えており、 サポート対応もしてくれます。

詳しい違いは、PandoraFMS のホームページにまとめられています。

http://pandorafms.com/Soporte/pricing/jp

なぜ PandoraFMS か

では何故 PandoraFMS を使ってみようと思ったのでしょうか？ 監視ツールとしては、Naigos と Cacti を利用してきたのですが、監視の運用負荷を 減らしたい！と思ったことが理由です。

監視の運用負荷

1) システム監視とリソース監視が別システム。

Naigos には、リソース状況を分かりやすくグラフ表示してくれる機能が無い為、 システム監視は Nagios 、リソース監視は、Cacti と2つのシステムを使っています。

Cacti のグラフは見やすく使い易いのですが、新環境の監視を設定する時など、 2つのシステムに設定を行うので面倒だと感じていました。

PandoraFMS では、システム監視とリソース監視が1つのシステムで実現できます。 リソース状況の表示も Cacti と同じようにグラフで見やすく使い易いです。

2) そもそも手動で設定したくない。

社内のシステムなど、様々なソフトウェアが動作している環境では、サーバ単位に手動で 監視を設定するしかありません。

しかし、弊社の様にサービスを提供する場合、動作するソフトウェアや導入する監視項目は、 固定できます。監視の導入を自動化することで、工数の削減だけではなく人為的なミスも 防ぐことが出来ます。

PandoraFMS のシステム監視（ネットワーク監視を除く）は、サーバから Push する方式なので、 サーバ構築時に サーバ側に PandoraFMS agent のインストールと設定ファイルを設置すれば 自動で監視が開始されます。

サーバの構築に chef 等の自動化ツールを使用することで、構築から監視までの自動化が 可能になります。

3) GUI による管理が便利

Nagios の設定はテンプレートに汎用的な定義を作成し、それを継承する方法で 行いますが、設定ファイルではどのサーバがどのテンプレートを継承しているかが 分かりにくいと感じていました。

PandoraFMS では、管理GUIで通知先などの設定が可能なため、継承関係が分かりやすく、 簡単に設定変更が行えます。

まとめ

以上、PandoraFMS について少しは理解を深めていただけましたでしょうか？

PandoraFMS は API が豊富なため、オープンソースでも使い方次第では、 必要な監視を網羅できると考えています。

EIPプールをつくったお話

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を蓄えておけるプールを作りました. 簡単なフローは以下のとおりです

1. 定期的にEIPを「申請解除待ち」状態としてためる
2. 自動的に申請を出す
3. 別タスクで定期的にRBL等から解除されているか確認をする
4. 解除されたことが確認されたら「申請解除」状態にする

また上記フローとは別に以下の機能もつけました (詳しい説明は割愛)

• ログを残す (基本中の基本)
• 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ユニットがどのようにして効率化をしているかご紹介できればと思います. つたない文章でしたが最後まで見て下さりありがとうございます