まいんだーのはてなブログ

はてブなのはてブロなのどっちなの

ソフトウェアエンジニアだけでサービス運用できる環境を作って失業した話

はじめに

このエントリは非常にポジティブで技術的なチャレンジに関するまとめであり求人エントリでもあります。

まとめ

昨年後半から、急成長するサービスを支えるため “どオンプレ” な環境で作ったサービスをクラウドに持っていく仕事をしていました。

クラウドのオイシイところを押さえられるよう作り変えをした結果として “Infrastructure as Code” を実践することになり、結果としてソフトウェアエンジニアだけですべてがコントロール出来る状態になり、インフラおじさん業が不要になりました。

そういった環境で働きたい "腕の立つITエンジニア(特にスマホとサーバサイド)" を募集しています。

発表資料&箇条書きで振り返る最近の動き

AWS Casual Talks #3

  • https://github.com/myfinder/aws-casual-3/blob/master/slide.md
  • クラウドに移すことを決めて、opsリポジトリを作って色々まとめ始めた頃
  • この頃はまだAutoScalingとかやってなかった
  • 毎度インスタンスを差し替えるのではなく、Ansibleで継続的にconfigを更新するやり方をしていた
  • ログ集計をオンプレのHiveから、Redshift or BigQueryどっちでやるかを検討していた時期
  • セットアップが面倒なものをDockerで運用したら楽になるんじゃと思って使い始めたのもこの頃
  • 実際Docker使うと楽になった

AWS Advanced Users Meetup vol.2

  • https://github.com/myfinder/aws-advanced-users-meetup-2/blob/master/slide.md
  • このタイミングから、Ansibleを継続適用するのをやめ、イミュータブル方向に一気にかじを切った
  • デプロイを種サーバからでなくS3から行うようにしたのもこの頃
  • AutoScaling対応をして、弾力的なアプリサーバの運用ができるようになった
  • 結果として、いわゆる “Infrastructure as Code” を実践することになった
  • Mackerelの威力を思い知った
  • この時注意していたのは “必要以上にクラウド側特有の機能に頼らない(学習を必要としないようにする)” ということ、これが後々、別のソフトウェアエンジニアへの情報共有で重要なポイントになった

Mackerel Meetup #3 と Monitoring Casual Talks #7

  • https://github.com/myfinder/mackerel-meetup-3/blob/master/slide.md
  • ここでこれまでの総まとめ的な発表をした
  • モニカジ7では “インフラエンジニアが死んだ” というタイトルで失業した話をした
  • この頃には今までやらなくてはいけなかった仕事の大半がなくなった
  • この後は細かいチューニングやら、ちょっとイケてない部分や余計な手順を省く仕事をしていた

直近の改善

  • Dockerコンテナでデプロイしていた諸々をすべてPacker->AMIという形に変え、Dockerを使うのをやめた
  • この方がすべてのコンポーネントをソフトウェアエンジニアが把握しやすいというのが理由
  • DockerコンテナもPackerから作ることができるので、最初からDockerでやるよりも汎用的だし未来の可能性を狭めない
  • packer build時にServerspecを使って、セットアップ状況をチェックできるようにした
  • ピークとそうでない時のトラフィック差が大きいサーバは Spot Instance 使うようにしてコストを大幅に引き下げた
  • AutoScalingが走っている時にdeployすると、タイミングによっては古いコードのままサービス投入されてしまう問題があったのでデプロイロック機構を入れる
  • 更に増えていく機能やデータをうまいこと扱うため、DynamoDBとその周辺ツールセットの検証と引き継ぎ

結果

  • “どオンプレ” だった環境が下記のような技術要素に置き換わり、スケーラブルで、かつソフトウェアエンジニアだけでコントロール可能で柔軟さと機動力をあわせ持ったシステムに生まれ変わった
  • サービス監視/インスタンス管理をMackerelで
  • インスタンスのセットアップやAMI作成をPackerで
  • セットアップ状況の保証をServerspecで
  • トラフィックが上下する部分はAutoScalingで
  • 量の多いログ集計はBigQueryで
  • ほとんどコードで管理できるようになり、新しい取り組みにソフトウェアエンジニアがチャレンジしやすい環境ができた
  • かくしてインフラおじさんとしてやっていた仕事をおよそ無くすことができ、更に運用コストも大幅に減らすことができ、私は堂々失業することになったのだった

とても大事なお知らせ

このエントリにある取り組みをしたエム・ティー・バーン社のAppDavisというサービスはいま絶賛成長中であり、機能開発がとても活発です。

↑に書いたようなチャレンジにも大いに理解のあるチームで開発をしたい ”腕の立つITエンジニア(特にスマホとサーバサイド)” を募集しています。

ご興味、ご関心を持っていただけた方は気軽に 社長 に声をかけるか、 こちらのフォーム から "エム・ティー・バーンの話を聞かせろ" と送ると良いでしょう。

www.fout.co.jp

おわりに

丸2年エントリでも書いたことですが、自分がこれまで取り組んできたことで重要な点は “開発/運用の品質/スループットを上げつつコストや納期を勘案して、サービス展開の可能性を最大化する” ということだったように思います。

今回のチャレンジでは、振り返ってみると意識していた原則が2つあって "何か新しいものを1つ入れるときは既存の何かを2つ以上減らせること” "ボトルネック以外触らない" というもので、それが結果として自分の仕事を無くすことにつながっていったわけです。

そういうわけで、今後はもっと違うことにチャレンジしていこうと思っております。今後とも何卒よろしくお願い致します。