突撃！隣のDevOps パート1【Wantedly編】
はじめに
こんにちは！おおはしりきたけです。今回は、突撃！隣の開発環境ではなく、突撃！隣のDevOpsというタイトルで、イケてる開発会社さんのDevOpsについてインタビューさせてもらいました。パート1として突撃！隣の開発環境のパート1でも紹介させて頂いた、WantedlyさんにDevOpsをどのようにやっているのかを伺ってきました！
突撃！隣のDevOpsとは
突撃！隣の開発環境では各会社さんの開発の方法や、どのような体制で開発をしているのかという形で、「開発」に焦点を当てたインタビューをさせていただいていました。実際、ソフトウェアサービスと言うのはリリースしてからがスタートであり、日々の改善活動や安定運用を行うため、開発（Development）と運用（Operations）が協力し合いながらビジネス要求に対し、早くかつ柔軟に対応していくかが求められます。そこで、突撃！隣のDevOpsでは、各会社さん毎にどうやってDevOpsを文化、プラクティス、ツールと言う観点でどのように実現しているかについてインタビューを行っていきます。
Wantedly紹介
どのようなサービスをやっている
「シゴトでココロオドル人をふやす」というミッションを掲げ、ビジネスSNSのWantedly（ウォンテッドリー）を展開しています。 Wantedlyには、シゴト仲間とつながり、つながりを管理する機能や、自分のシゴトに関する情報をまとめておけるプロフィールページの他、会社に遊びにいける機能があります。最近では、ポートフォリオサイトのCaseや会社フィードという機能の追加されました。また、ビジネスチャットサービスのSyncや、Wantedly Open APIといったAPIも提供され、益々サービスが加速しています。
担当者の方の仕事内容
今回のインタビューは、Wantedlyのインフラチームの方にお答えいただきました。インタビューに答えていただいた方と仕事内容は以下になります。
- 相川さん@awakia
- チームのリーダー、作業自体はメンバーの方に任せており、次の構成をどうするかなどを調査し Blueprint を作成している。他は採用とか初期メンバーっぽいことしています。
- 坂部さん@koudaiii
- 主に本番環境の安定稼働と自動化を進めています。最近は golang で AutoScale から instance に付けられる tag を元にサービスを自動で起動させる等を開発しています。また、kubernetes の検証を行っています。
- 藤田さん@dtan4
- 主に開発環境まわりの改善に力を入れている。具体的にはテスト高速化や Terraform によるインフラ自動化の導入、便利ツールの開発など。最近は社内向け簡易 PaaS を作ったりしています。TeraformingというAWS の API を叩いて既存のインフラリソースから Terraform のコードを生成するツールも作っています。
- 斎藤さん@munisystem
- 2月からインターンとして参画し、デプロイツール周りのコード、Kubernetesの検証しています。
写真は、藤田さんと坂部さん
DevOpsについて
文化
御社の考えるDevOpsの定義とは？
- 定義
- 「エンジニアの生産性をあげる」 => メトリクス: エンジニア1人の1営業日あたりのコミット数を増やす
- 文化的なConstraints
- 「Code wins Arguments」を支えるインフラ => 変化に強いインフラ
なぜDevOpsに取り組んでいるのか？
DevOps の領域でよく出てくる CI とかデプロイツールとかはある程度の部分は、昔から当たり前の領域で行っていましたが、エンジニアの人数が増えていった時、生産性が落ちていると感じ、実際に1人あたりのコミット数等の数値を見ていても下がっていたのが経緯としてあり、生産性の向上を目指すために取り組んでいるとのことでした。Wantedlyさんでは、「エンジニアの生産性をあげる」というところを定義とており、エンジニアの生産性の指標としては、issueやプルリクは、棚卸しのタイミングで数字の揺れが大きくなるので、コミット数を指標としているそうです。
具体的には、GithubのNotificationを見るワークフローの確立、ちゃんとテスト速くしようとかを目標に入れられるようになった、DomoというBIツールを導入して評価ポイントの明確化を行ったりしています。Wantedlyの開発フローは相川さんがQiitaに開発フロー研修@Wantedlyというタイトルで投稿しています。
Wantedlyさんでは、「純粋ににDevOpsやりたいメンバーが多いため取り組んでいますw」とのことでした。
写真はスタンディングデスクで作業する相川さん
DevOpsにおいて重要な考え方とはなにか？
DevOpsが目的ではなく、組織としての成長を考える上で、行き着く結果が、巷でDevOpsで言われている解決手段なこともあり得るぐらいの認識で、いわゆるDevOps的な部分では、以下の部分を行っているそうです。
- CI
- インフラのコード化
- 自動化
- ChatOps ※自動化とChatOpsは全部を自動化するというよりは工数が多いものから順に自動化を進めている。
DevとOpsをどのように連携させているのか？
以下のSILOの図が目指す部分とのことでした。
引用: Dockercon State of the Art in Microservices
- 縦割りじゃなくて、プロダクトごとのチーム + Platformチーム の構成
- プロダクトごとのチームとPlatformチームは、「お願い」ではなく、APIでやり取り
チームごとに、使うバックエンドを決められるように。RedisとかElasticsearchも、DockerfileでOpsじゃなくてDev側が用意できるようにしているとのことでした。ただし、今やっている最中で、割り込み依頼でOps側が用意することもあるのことです。
DevはDevで、それぞれサービスを伸ばす部分で高い目標を持っているので、仕組みで解決している部分も多く以下のような施策をやっているのとことでした。
- 1日決めて、技術的な負債を解消する日 => 負債返済日
- ビジネス側に寄せられる問い合わせの一次請けを持ち回りで => BizQuestion
負債返済日は、1日というタイムボックスを決めてやっている施策で、例えばRubyのバージョンアップなども負債返済日に行ったりするそうです。1日という制約があることで、逆に集中でき効率よく作業ができるとのことでした。負債返済日ではなく、リファクタなどはいつの間にかやっていることも多いそうです。またBizQuestionは、ビジネス側に近いエンジニアに質問が集中してしまい、その対応に1週間の半分以上を使っているというような状況があったため、1次請けを持ち回りで対応するようにしているとのことでした。
チームのメンバー構成はどうなっているのか？
インフラチームは、コードの書けるインフラエンジニア + 低レイヤ好きなRailsなどのバックエンドエンジニアで構成したいと思ってるそうで、現在は上述した4名で作業を行っているとのことでした。
DevOps的な面では、負債返済日やBizQuestionの施策は、インフラチームだけでなくデザイナー含めた開発チーム全員が行っているということです。
- 負債返済日 (1ヶ月半に1回ぐらい)
- BizQuestion (お問い合わせからの回答・不具合改修などを持ち回りで3人ずつ1週間交代)
また、インフラチームとしては、コードになっていないものは、基本的に評価しないそうで、インフラのコードもコミット数に入る形で仕事をしているとのことでした。
新メンバーへのキャッチアップの支援をどのようにやっているか？
引き継ぎのタイミングで後々使えそうな資料を作っており、作業しているそばからQiitaに上げることも多々あるとのことでした。Qiitaのメリットとしては、ググれる、周りの人からフィードバックももらえたり、外に出す以上、変な技術も選定しにくいとのことでした。また、社内の GitHub Issue上の引継ぎ資料には演習問題もあり、コレを使って技術のキャッチアップをしていくことも多いそうです。
DevOpsを進めていく上で苦労したことなどはなにか？
苦労した点としては、定着のさせ方で、ある程度独断で決めて引っ張る、いきなり全員に導入せず、最初に熱意を持ってやってくれる人に集中的に教えて進めていき、全体での発表場を有効に使い展開していくとのことでした。ただし、進めていく上で課題は出るので、KPTなどの振り返りをして、入れた後に改善しているとのことでした。
例: - 非同期コミュニケーションの場合 => まず小さいチームで試して、新卒研修のタイミングでまとめて新卒から広め、最終的にビジネスチームまで広めた - Domoの場合 => 興味を持ってくれた方にまず積極的に教え使ってもらい、その人が別の人に教えれるような体制にした - BizQuestionの場合 => ランダムでメンバー編成するのではなく、ある程度恣意的に行い、確実に上手くいくようなメンバー構成にした
プラクティスとツール
CI、デプロイ、構成管理どのようにやっているのか？
- CI:Wercker、TravisCIやCircleCIもチームごとには利用していることもある
- Deploy:Sap(SSH-Capistrano)
- AWS/構成:Terraform/Dockerfile
自動テストは、どのレイヤにどの程度行っているのか？
何をユニットテスト、結合テスト、総合テストと言うか世の中的にも揺れている気もしますが、Wantedlyさんでは以下の用に行っているとのことでした。
- モデルとかレベルのユニットテスト
- RailsレベルでのRequestテストは主要な機能(ログイン、応援、応募等)については書いている
- 結合テストは、WebMockとかを使って、基本的にはユニットテストとして書けるように行っている
- 総合テスト: テスターが2人いる。モバイルやDesktop App等、バグがでた後の変更が難しい物をより重点的に行なっている
- インフラのテストもある程度行っている（by TravisCI)
デプロイはどのような方法でやっているのか？
sap(SSH-Capistrano)という、自作ツールを用いて、blue-green のコンテナデプロイをしているそうです。
sapは、Capistranoベースのデプロイコマンドを1つのサーバーのDockerコンテナ上で実行します。それにより各エンジニアがCapistranoコマンドを打つ時と比べ、以下の様なメリットがあるそうです。
- デプロイに必要な様々な鍵や環境変数を個人で設定しなくてよくなる
- デプロイ方法が変わるようなインフラの構成変更時にも、各エンジニアは何もアップデートする必要がない
- デプロイ時の各個人の作業がコンテナのログとして残っているため、後で誰でも確認できる
障害をどのように検知して、どのような対応フローで進めているのか？
詳細は、坂部さんがQiitaに纏めているWantedlyを支えるモニタリングに書かれていますが、以下のツールを利用し、検知から通知まで行っているそうです。
- NewRelic：Applicationのモニタリング
- Datadog：System、Eventのモニタリング
- Pagerduty：Alert通知
- Logentries：Log保管
- HoneyBadger：ApplicationのError管理
Issueを作り、作業をコメントで記載しながら進めており、Error対応後は、そもそもどうあるべきかを考えて改善を進めているとのことでした。
チャットツールなど補助的なツールはどのようにつかっているか？
チャットツールなどの補助的なツールとしては、Github、Slackや自社サービスのSyncなどを利用しているそうです。
- Github Issue
- Slack Notification
- User Voice部屋がある
- TwitterとかApple Storeの評判からも気づける体制に
どのようなメトリクスを取得して、どのように改善をおこなっているのか？
障害監視ツールでは、上述したとおり、NewRelic、Datadog を使っていますが、日々の改善の為に以下のメトリクスも取得して改善を進めているそうです。
- 一人あたりのコミット数
- 障害時間、デプロイ時間、テスト時間
- 1人あたりの管理台数
ただし今は、Kubernetesを使った基盤づくりを主にしているのであまりメトリクスは見ず、導入できるか出来ないかが判断基準に対応を行っております。
最後に
目指すところはどこか？
各チームが責任を持って成長出来る組織ができている状態とのことで、インフラチームは一人あたりの管理しているインフラのリソースは、最低1000台を目指しており、管理もちろんサービスは小さいもの含め数百は動いている形を目指しているとのことでした。今のChef/Ansible等の構成管理ツールでは、数の増加には耐えられるけど、種類の増加に耐えられない気がしていて、100ぐらいのオーダーで頭うちになりそうと思っているそうで、簡単に記述できる設定ファイル(今のところDockerfileを想定)で、Dev側に必要なインフラ構成を書いてもらい、Ops側はクラスタの管理に集中するという状態が理想とのことでした。
- Dev が自発的にサービスを立ち上げられる環境がある
- 決まりきった作業はすべて自動化されている
- API を叩けば、欲しい情報を取得できる
相川さんがネタとして「自分の仕事が機械にとられました」という退職エントリを書くことというお話をされていたのが印象的で、この形が理想形なのかなとも思いました。
その他
Wantedlyさんでは、Dockerをプロダクション環境に入れているそうです。Dockerは開発環境で利用されることも多いですが、インスタンスに対して、Web、Worker、Schedulerというようなタグをつけ1コンテナ1プロセスという単位で管理しているそうです。AdHocに環境構築を行っていると、インフラチームがボトルネックになるし、一人あたりの管理しているインフラリソースを1000台目指しているので、Devの方が簡単に利用できるDockerはオススメとのことでした。
インタビューが終わり、自転車で帰宅する藤田さんと相川さん
今回登場したツール
チャットツール
CI
デプロイ
- sap(社内ツール)
構成管理
監視＆通知
まとめ
Wantedlyさんでは、以下の考え方がベースにあります。
- Code Wins Arguments
- User First
- Simple is Not Easy
特に印象に残ったお話として、Code Wins Argumentsのお話があり、チームで1時間ミーティングするならコードをかこうという考え方のもと、エンジニアであれば、仮説を考えてあれこれ考えるよりも、プロトタイプを作って検証することや、営業であれば、エンジニアに頼む前に企画書を書いて5社程度の確約をとってきて、これなら行けると思ったらエンジニアに依頼するという形で仕事を進めているそうです。今回取材させて頂いたインフラチームでもCode Wins Argumentsを可能にするインフラを考えており、変化に強いインフラや、まず出してみて結果を見ていくというこという文化を大切にしているそうです。詳しくは坂部さんのDeveloper Infrastructure in Devlove Kansaiに書かれています。 サービスの成長を加速させるためにDevとOpsが融合し短いライフサイクルでどのようにビジネス価値を出せるかというのが私のDevOpsの考えですが、Wantedlyさんは今まさにDevOpsを実践し日々の課題に取り組んでいるのだなと思いました。
Wantedlyさんでは、「一緒にツールを作るインフラエンジニアをウォンテッド！」ということでインフラエンジニアを募集中とのことでした！
最後に集合写真をとらせてもらいました！左から斎藤さん、藤田さん、坂部さん、相川さんそして私です。
