「インフラエンジニアの現場における仕事と文化」のDiff #DevKan
2016年2月5日のDevLove関西の表題のイベントに参加してきました。（いちおう受付スタッフも）
Developer Infrastructure in DevLove Kansai
話し手：Wantedly 坂部広大さん
www.slideshare.net
Devlove現場甲子園東日本大会での坂部さんの話がもう一度聞きたいと思って、DevLove関西でもやってもらえました。 念願かなった感じです。
syncメッセンジャー
１月からsyncというメッセンジャーアプリをローンチしたとのこと。 syncはfacebookのメッセンジャーが仕事の話が混じってしまうことを嫌う人のために、仕事領域のメッセージサービスとして特化した形を目指しているそうです。
「話を聞きに行く」「応募情報の自動入力」のボタン(OpenAPI)を作った話。
東日本大会のときはわかっていなかったのですが、相川さんというかたとタッグを組んで実現されてたのですね。 ただOpenAPIを作るというだけではなく、企画書を書いたり、使ってもらえそうなところを訪問してちゃんと営業までする、というのがインフラエンジニアとしての領域、もしくはエンジニアとしての領域を『越境』していると感じます。 そしてそれが、「Ownership」ということなのかと。 そうでもしないとWantedlyのメンバーとして生き残れない感じがあるんじゃないかなぁと邪推してしまいます。
インフラエンジニアがボトルネックにならないために
Wantedlyのサービス開発はとにかくプロトタイプを早く作り、どんどん早くリリースして検証したいという感じらしいです。 Devのエンジニアがリリース依頼して、インフラがリリースするという流れだとタスクが溜まってインフラチームがボトルネックになる。
解決する道は２通り
- インフラエンジニアを増やして人海戦術
- インフラの質を上げる
Wantedlyは後者のアプローチを取ったそうです。
『Facebookは5人で10万台のサーバーの面倒を見ている。俺たちもfacebookになろうぜ！』
『変化に強いインフラ』を目指すために
- 自動化
- セルフサービス化
を実現する。 直近の取り組みとしてCoreOSにすべてのコンテナを置き換えたとのこと。 ChefやPackerを使った構築の自動化だと、結局は「秘伝のタレ」化がなされてしまい、アプリのエンジニアがどこを変更すればいいかわからなくなるとのこと。 Dockerfileだけにしてしまえばインフラエンジニアじゃなくてもわかる。
GitHub Issueのフル活用
これはエンジニアだけでなく、ビジネスサイドの人もそうです。 そこに「Why」と「What」を必ず盛り込むため、チーム間でIssueのバトンタッチができるとのこと。 そして、PullRequestで「nginxのワーカープロセスを議論する」ということができているとのこと。
『インフラエンジニアこそ情熱的に仕事をする。』
感想ですが、どうすればこのように越境するエンジニアリングができるのか、ということを考えながらこれから先歩んでいきたいと思っています。
WhyとWhatを大切にし、必要ならばどんどん企画書を書き、営業もできるように。。。。
地道にAWS構築自動化に取り組んでいるお話し
話し手：Serverworks 永田明さん
www.slideshare.net
Serverworksのインフラエンジニアとしての構築のお仕事
サーバーワークスの提供しているのはAWSを中心として様々なサービスを組み合わせて最高のサービス基盤（インフラ）を提供すること。 そのため、セールスをしている人もセールスと言いつつ凄腕のエンジニア。 大体の構築はわかる。
もともとは、BacklogのWikiにパラメータシートをMarkdownでうめこみ、それをもとにお客様とやり取りするスタイル
そのほかAtlassian Confluenceにノウハウをためているとのこと。 でも、、「その情報あったんかい！」てなることも多いとのこと。
Wikiに記述されたパラメータをAWSのマネジメントコンソールからポチポチ転記。 その結果としてミスすることもある。
属人性が非常に高い設計フェーズだった！
自動化タスクフォース
これではあかん、ということで構築を自動化しようという運動が持ち上がったそうです。
最初にやったのはYAMLをJSON(AWS CloudFormation)にするスクリプトの作成
やってみたけれど、課題が…
CloudFormationのそもそもの課題として動かないとどこがおかしいのかわかりづらい。 AWSマネジメントコンソールは入力値のチェックもしてくれるし、元のほうがよかったのでは…
でも
そもそもAWSはプログラマブルなサービス そして我々はトップレベルのベンダー
自動化を続けるために、小さく早く試して、たくさん失敗できるようにしよう
まず、達成すべき課題として以下の２つがある * YAMLの二重管理 * スクリプトの実行環境がローカルで毎回アップデートについていかないといけない
これを解決するために
WEBアプリ化
Jenkinsによるバッチ処理実行するようにすることで、実行環境が常に最新化されスクリプトが実行する人が気にしなくてもいいようになった。
そして、Jsonだけじゃなく、Markdownを生成。
生成されるのは、属人的に作られたものじゃなく、フルスペックのパラメータ表。
これによって、ひな形のYAMLができて、無難な設計が共有されるように。
いわば『秘伝のタレ』
自動構築化後の課題
自動で構築しても確認は必要。 そして、確認は目視。 CloudFormationは動かないとどこがおかしいのかわかりづらい問題。 逆に動くと快感らしい。。。
確認のためにRSpecをもととしたWebアプリをつくる、、、ということを目指しているそう。
自動テストの文化を作るところから再スタート
感想ですが、今までやってきたことがアンチパターンになる場合もある、という言葉に深く共感します。 そのために、改善と軌道修正をやめたら負けということも。
自分も今の現場で自動化の取り組みをしていますが、今まで築きあげてきたものがレガシーになったときに、捨てたり式年遷宮的にちゃんと切り替えができるように考えていかなければいけないんじゃないかなーと思いました。
全体の感想
スタートアップとクラウドのトップベンダーという２つの現場の文化の違いはとても感じられたし、自分の現場とも比較することができ、とてもよかった！
坂部さん、永田さん、会場のMOテックスさん、参加してくれた皆さま、本当にありがとうございました。
