突撃!隣のDevOps2018年09月10日aratafuji(11)234234件のシェア(すこし話題の記事)この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。はじめにこんにちは、DevOps導入支援担当の藤村です。突撃!隣のDevOpsが帰ってきました!パート1からなんと2年ぶりのパート2、2といえばペア、ペアといえばPairs!ということで、今回はPairsを運営するエウレカさんにお邪魔して、DevOpsに関して根掘り葉掘り聞いてきました!突撃!隣のDevOpsとはパート1からあまりに時間が経っているため、改めてこのシリーズの趣旨について再掲します。突撃!隣の開発環境では各会社さんの開発の方法や、どのような体制で開発をしているのかという形で、「開発」に焦点を当てたインタビューをさせていただいていました。実際、ソフトウェアサービスと言うのはリリースしてからがスタートであり、日々の改善活動や安定運用を行うため、開発(Development)と運用(Operations)が協力し合いながらビジネス要求に対し、早くかつ柔軟に対応していくかが求められます。そこで、突撃!隣のDevOpsでは、各会社さん毎にどうやってDevOpsを文化、プラクティス、ツールと言う観点でどのように実現しているかについてインタビューを行っていきます。エウレカ紹介どのようなサービスをやっている「かけがえのない人との出会いを生み出し、日本、アジアにデーティングサービス文化を定着させる。」をビジョンに、「すべての人が、人生の可能性を拓いていける世界をつくる。」をミッションに掲げ、私たちのサービスで、誰かの人生をよりよいものにすることを目指して、恋愛・婚活マッチングサービスの「Pairs」と、カップル向けコミュニケーションアプリ「Couples」の運営をしています。今回のインタビューは、SREチームの方にお答えいただきました。山本真嗣さんSREチームシニアエンジニアSREチームとはSREチームは、「会社の目指すビジネスの実現の阻害確立を上げる要因を全て排除する事」をチームのミッションに掲げ、以下の6つの戦略の推進を担っているチームだそうです。99.95%の可用性を目標に、事業的な機会損失を最小化するブランドイメージ失墜につながるクリティカルなセキュリティリスクを撲滅する運用自動化および自己修復可能なシステム基盤構築による少数精鋭での運用体制を確立する定期的なキャパシティプランニングに基づくコストコントロールを行うことで利益率の向上へ寄与する顧客価値提供を最速化する為のリリースエコシステムの改善と安定化をはかる事業価値最大化の為の施策サポートを行う運用体制については、ビジネス規模の拡大とともに運用負荷も比例して拡大しては意味がないので、ビジネス規模が拡大しても今の運用工数が比例しないシステム基盤作りを特に意識しているとのことでした。システムの安定稼働のみに注力するのではなく、マイクロサービスやデータ分析基盤の構築、またAIチームと共同で目的外ユーザー(Pairs上でセミナーの勧誘など、本来の目的ではない使い方をするユーザー)検知システムの構築などもSREチームが担当しているそうです。SREチームは全員で6名。メンバーの経歴はバラバラですが、皆が開発経験者ということでDev側の視点やニーズを理解できていることが強みだと話されていました。後述するダッシュボードを見ながらスタンディングミーティングするSREチームの皆さん。顔が見えないのでこっち向いて下さーい。左から山本さん、恩田さん、原田さん、坂田さんです。上記のような定義を掲げてもらいましたが、恩田さんが入社された2015年4月の段階では、エウレカにはOps的なインフラチームは存在しておらず、CTOと新卒メンバーが開発しながらインフラも見ているような状況だったそうです。その後事業が伸びるに従ってパフォーマンスなどの問題が出始めたので、インフラチーム(現SREチーム)が発足したとのことで、特にエウレカにおいては開発チームと運用チームの間で衝突が起きていたわけではないとのことでした。することで、結果としてビジネスを成長させるため。DevOpsにおいて重要な考え方とはなにか?重要な考え方DevOpsという言葉からではなく、そもそもの課題や目指すべき理想の開発体制やサイクルからの逆算で考えること。ツールやエンジニアリング戦術ありきで考えないこと。ビジネスの成長がゴールであり、そのためにDevはいかに速くフィーチャをリリースするか、Opsはいかにシステムを安定稼働させるかに取り組んでいるとのことです。DevOpsではよく手段が目的化されてしまうと聞きますが、あくまで目的はビジネスの成長であり、そのためには広い視点を持って考え、常に改善に取り組んでいるという点にとても共感しました。DevとOpsをどのように連携させているのか?DevとOpsが「ユーザ体験の最大化」という同じ目標へ向かっていること、そして改善を二人三脚で継続的におこなうことが重要と考え、DevとOpsでサービスレベル目標(SLO)を共有しているそうです。SLOの達成度やユーザのサービス利用体感に関わるメトリクスに変化がないかひと目で確認できるレポートを自動生成して社内サーバにホスティングし、Dev(6〜7名)とOps(SREチームの6名)が参加するパフォーマンスモニタリング会を週次で開催して、その中でダッシュボードをチェックしているとのことでした。チェックした結果、対応すべき事項がある場合はキャパシティ上限に従いDev、Ops(SREチーム)それぞれがタスク(多くても3つ程度)を持ち帰り、翌週までに対応を完了させるような取り組みを継続しているそうです。開発チーム責任者に最初話をもちかけた時はうまく改善サイクルが回るか分からず、形骸化や負担が増えないかを心配していましたが、結果として非常にうまくいったと考えていて、品質の向上だけでなくサービス品質に対する開発者としてのスタンスというか、文化的な醸成の場としても非常にうまく機能しているとお話しされていました。いった継続的な改善活動がDevOpsの文化面で非常に重要だなと思います。Datalabで作成しているそうです。WebサーバログアプリケーションログCloudWatchログ新メンバーへのキャッチアップの支援をどのようにやっているか?新メンバーへのキャッチアップ支援は、Terraform、Ansible、Packerのコードを皆で読み合わせる、モブコードリーディング方式で実施しているそうです。codeの実践の結果として自己定義的かつシンプルな状態が維持されていることを重視していて、コードを読むだけでは理解できないような複雑な構成にはそもそもしないという考え方を徹底しているとのことです。今回インタビューを受けてくれた山本さんも、SREチームにジョインしたタイミングで実践したそうです。DevOpsを進めていく上で苦労したことなどはなにか?苦労している点として挙げて頂いたのは以下の二点。ユーザからみた品質低下と、システム上の数値で検知した異常の結びつけモニタリング上では異常値を示していたとしても、それがユーザーにとってどういう影響があったのか、他よりも優先して対応する必要があるのか、つまり何をもって異常とするかの定義に苦労していたそうです。現状はシステムメトリクスがユーザ体験にどのように影響するかをはっきり定義することはできない前提でステークホルダーにも説明していますが、今後はユーザーサイド(端末)でのメトリクスも取得することで、数字で説明していけるような構成を目指しているとのことです。「xxというユーザ価値を実現したい」という事業部としての要望と、「yyというエラーを直してユーザ体験を向上させたい」というSLO達成観点でのタスクの優先度判断が日々発生するので、これらをどう折り合いつけていくのかに悩んだそうです。当初はパフォーマンスモニタリング会の場にCTOなど意思決定ができる人を呼んでいたそうですが、今では社内での共通認識の合意形成が進み、SREチームに権限委譲されているそうです。事業レベルでもチームレベルでも優先順位が一意なBacklogで開発項目を管理しており、なぜこのような優先順位になるのかの根拠を前出のダッシュボードを使って説明することで説明責任を果たしているそうです。PackerによるゴールデンAMIモデル注目すべきは、これらツールの中心にあるSlackのChatopsの存在です。開発者はChatops経由でコミットのDiffを見たり任意の環境へ任意のバージョンのコードをデプロイ、ロールバックすることが可能になっているそうです。Groupの調整やインスタンスの検索、ジョブキューの確認からログの閲覧まで、すべてChatopsで実現しているそうです。恩田さんの入社時は、デプロイでCapistranoを使っている程度で、インフラのコード化は全く実現されていなかったそうです。そこからコツコツとコード化を進め、チームビルディングも行なって今の構成に至ったとのこと。これらの取り組み以外にも、開発環境やリリース前検証環境、カナリアリリースの整備、開発者が安全かつ迅速なリリースをサポートする仕組みを整備したり、次はカオスエンジニアリングに取り組もうとしているなど、日々進化の止まらない攻めの姿勢が本当に素晴らしいと思いました。基本気づいた人が対応。オンコール対応はSREチーム。ないと形骸化する狼アラートが多いと、アラートを異常とみなす文化自体が損なわれるので中長期的に危ないこの中で印象に残ったのが、障害時に自動でSlackチャネルが作成される仕組みと、"検知できても打つ手なしでは意味なし"という考え方です。前者は、一般的に共通チャネル上でやり取りされることが多いと思いますが、経験上会話が入り乱れて混乱することもあったので、専用チャネルが自動で作成されるのはとても良いと感じました。Scalingする構成にしておいて特に通知はしない方が結果的には良いという考えです。恩田さんが特に強調されていたのが、MTTR(平均修復時間)の最小化を特に重視している点でした。結局のところ、あらゆる障害を未然に防ぐことは不可能という前提において、障害の発生をいかに早く検知し、激速で戻せる(ロールバックできる)ようにしておくことでSLOを達成するというアプローチは非常に理にかなっていると思います。私自身、今まではデプロイ、リリース前にいかに障害を防ぐかという視点で、手動の確認などに多くの時間を費やしてきてしまっていましたが、そのような辛いアプローチをとっても必ず障害は発生してしまうので、それならば障害は発生する前提に立って手段を講じるべきでしょう。環境としてはプロダクション環境と全く同じ構成のステージング環境を構築しているとのことで、プロダクションだけで発生するような障害を無くすとともに、プロダクション環境で障害が発生してロールバックした場合でもステージングで再現できるようにしているとのことです。コスト面を考えると、ついステージングにそこまでコストをかけられなかったりしますが、必要なところにはしっかりとコストをかけているところも素晴らしいと思いました。されているMTTR(平均修復時間)の最小化をもってSLO(サービスレベル目標)が達成されて1,2の結果として、ビジネスが力強く成長している状態DevOpsという観点では、上記の状態を維持しながら改善を続けていきたいとお話されていました。今後目指しているのは自己修復的なシステムで、異常を外部から意図的に注入しても可用性、恒常性を保てるかを常に監視することで安定稼働していることを保証できるようなことに取り組んでいきたいとのことです。障害を想定した避難訓練を行いました)の事例を参考に検討を進めているそうです。皆様から今後の抱負!恩田さん売上が10倍になっても今と同じ仕組みで対応できることを意識している。事業の成長に対して運用コストも線形で増えてしまっていは意味がない。台数などは増えていっても、運用コストは線形にならないようにしたい。山本さんカオスエンジニアリングにチャレンジしていきたい。可能な限り多くの回数を試せるような仕組みを整えたいと考えている。一方でマイクロサービスのアーキテクチャやデータ分析基盤の構築なども行なっていきたい。坂田さん現状メトリクスはサーバサイド中心に見ているが、今後はクライアントサイドも含めて一気通貫で見れるような仕組みを整備する必要があると感じている。SREチームでは絶賛採用活動中とのことだったので、最後にどういった方に来てほしいかを聞いてみました。目的思考の強いエンジニア手段の目的化はだめだと理解しつつも、手段が目的になってしまうような熱量を持ったような人SREチームでは守りだけでなく、機械学習によるスパムの自動検知や、データ分析基盤の構築など攻めの施策も積極的に行なっているため、具体的にどういった利益、価値を提供できるかというのをボトムアップで上げていけるようなメンバーだと嬉しいとのことです。敷居は高いと思いますが、大変やりがいのあるチームだと思いますので、ご興味ある方はぜひご応募してみてください。Inc.まとめ私自身、今回のインタビューで特に印象に残ったのは以下の三点でした。今後われわれがDevOps支援を行なっていく上で、ぜひ参考にしたいと考えています。最後にエウレカのエンジニアの皆さんと、クラスメソッド山崎(右端)、藤村(左端)とで一緒に記念写真を撮らせてもらいました!エウレカの皆様、インタビューのご協力、ありがとうございました。2018で登壇されていたのでスライドを載せておきます。DevOps導入支援サービスを提供しています。110,092アジャイルと東南アジアが好き。リモート】クラスメソッドの会社説明会を開催しますクラスメソッドでは、AWS・AI・ビッグデータ・モバイルなどの技術職や営業のメンバーとして一緒にお仕事をする仲間を大募集しています。#cmdevio新型コロナウイルスの感染拡大を受け、本イベントを延期させていただくことになりました(開催時期未定)。お申し込みいただいた皆様には大変申し訳ございませんが、何卒ご理解いただけますようよろしくお願いいたします。AWSについてライトに色んな情報交換をしましょう。濱田孝治253re:Invnetの動画検索でもめちゃくちゃ便利ですが、その他ブログやホワイトペーパーやGitHubも横断検索できるので、是非一度使ってみてください。CAFEの他、NTTデータとセブンイレブンの取り組みや、サインポスト、Zippinなどの各社と流通・小売業との連携を業界マップに作成してみました。PolicyのConditionにaws:CalledViaというキーが追加されました。いったキーなのかご説明します。夏目祐樹409こんにちは、CX事業本部の夏目です。MacのタッチバーのタッチIDが非常に便利なのですが、Terminalでsudoを叩かないと行けないときに使えたらなぁと思ったので、情報を共有します。臼田佳祐295ワークフロー自動化OSSのn8nをAWS環境で建てて検証してみました。非常に期待できるサービスです。Fargateの勉強をしています。使ってみたい方は参考にしてください。洋介256SnowflakeがAWSの東京リージョン上で稼働するようになりました。データを日本に置けます。濱田孝治253re:Invnetの動画検索でもめちゃくちゃ便利ですが、その他ブログやホワイトペーパーやGitHubも横断検索できるので、是非一度使ってみてください。クラスメソッド株式会社が運営するAWS・iOS・HTML5に関する技術情報サイトです。