ニクニクドットミー

カッコいいおっさんを目指すエンジニアの厳かなブログ

初めてQiitaにアドベントカレンダーを作ってAutoScalingの話を投稿しました

皆さんアドベントカレンダーやってますか??

qiita.com ※投稿したアドベントカレンダー一日目の記事

Qiitaというエンジニア向けの情報サイトには毎年恒例のアドベントカレンダーというものがあります。これは12/1 ~ 25日まで、あるテーマに沿った記事を毎日交代で書いていくものです。同じ人が複数書いても問題ありません。テーマはそれぞれで、言語であったり、AWSであったりと多岐にわたります。
そんなアドベントカレンダーですが、企業毎のアドベントカレンダーも存在しています。 そんな中、いろんな企業がやっていたので自分もやってみたいと思い、いま勤めている会社のアドベントカレンダーを作り、AutoScalingについて記事を投稿させて頂きました。 なかなか無い機会なので、やろうと思った理由とAutoScalingを書いた理由をかる〜くメモっておきます。

なんでアドベントカレンダーやったの?

他の企業もやっているのを見て、あーやってみたいなーと思ったからです。書きたいもの書けばいいじゃんってノリでみんなやってくれないかなーと思いつつ、勝手に作りました。社内のHipchatで連絡したところみんな快く受けてくれて大変助かりました(中には僕に無理矢理やらされた人もいるとかいないとか(笑)

なんでAutoScaling?

Qiitaにも書きましたが、AutoScaling導入おじさんをやっていました。AutoScalingでサーバ構築のコストが大きく削減出来るのはすでに先人が導入してくれたお陰でわかっていたので、他のアプリに導入しまくってました。
そもそものBootstrap処理のソースコードを理解し、既存のデプロイフローを理解したのが一番のきっかけだったと思います。(本当によく考えられていて、素晴らしい処理だと思います) 導入おじさんをやっていたのですが、よい区切りがつけれたので、Qiitaに勉強になったポイントを書こうと思ったという訳です。

CodeDeployに移るの?

なんとも言えないところです。CodeDeployに移行するといまのデプロイの仕組みを変えなければなりませんし、AppSpecファイルを用意したりと大きな変化をアプリ、インフラともに強いられます。そこをクリアしてでも良いメリットが無い限りは思い切った舵取りは難しいだろうと思います。あくまでも個人の意見です。 いまのデプロイの仕組みは個人の環境に依存している部分もあるので、そこを全てAWSに丸投げ出来るのは嬉しいポイントだと思います。

Bootstrap処理はなにをしているの?

Qiitaではかなり端折って書いてます。まず最初にELBのヘルスチェックからNGになるようにしていたり、ELBからデタッチしたり、インスタンスのタグにLaunchConfigの名前、アタッチされるELBの名前を登録したりなどいろいろやってます。 説明するのがなかなか大変なので、必要なポイントだけ書かせてもらいました。さらにBootstrap処理はインスタンス起動時にStashから取得しています。アプリのソースコードに比べたらかなり軽量なので、Stashへの負荷は多少すくないですが、S3から取得するように変更したいなーと思っています。

なんだかんだで面白いイベント

お祭り感あるなぁと思いました。企業のアドベントカレンダーもすごい数(カレンダー数71、参加者数913!)ありますし、Goは人気ありすぎて、カレンダーが複数出来るし(笑) こうやって各々が普段やっている事や興味あることについて、発表出来る場っていいなと思いました。
このような機会を作ってくれたQiitaに感謝!そして参加してくれた会社の人に感謝!


AutoSaclingについてももちろん書いてます。オススメの本。