11:30~12:30

Door opens

11:50~12:10

【早期来場者特典】SRE NEXT 特別ヨガプログラム

エンジニアのかた向けに、肩こり・腰痛等を改善する椅子に座ってできるリフレッシュ法を紹介します。 是非お早めに受付をして、すっきりとした状態で本編を楽しみましょう！ https://sakura.yoga/2017/03/30/%e8%87%aa%e5%b7%b1%e7%b4%b9%e4%bb%8b/

11:50~12:10

準備

12:30~12:35

Opening

12:35~13:05

[A0] 分散アプリケーションの信頼性観測技術に関する研究

Webアプリケーションをはじめとする分散アプリケーションは複雑化の一途を辿っています。そのような状況では、システム管理者がシステムに変更を加えるときに、システムの信頼性がどの程度低下するのかを予測したり、障害発生時に短時間で回復することが難しくなっています。その結果、変更することに恐怖を感じ、変更に躊躇してしまいます。そこで、変更時の信頼性低下リスクを予測し、低減させる、つまり信頼性を制御することで、変更速度を向上させるというのが講演者の考えるSREのあり方です。そのアプローチの一つとして、メトリック、ログ、トレースといった異種混合の計測データを組み合わせて、システムの可観測性(Observability)を高める技術が注目されています。そこで講演者は、TCP/UDP通信とOSのプロセス間の依存関係を追跡するといった新しい計測手法に関する研究と、異種混合の計測データを格納し効率的に問い合わせるためのデータ指向アプリケーションの構成技術に関する研究に取り組んでいます。本講演では、研究背景としてSREをサイト信頼性の制御技術と定義した上で、研究内容の概要、および今後取り組む研究展望についてもお話します。

12:35~13:05

基調講演サテライト会場

13:20~13:40

[A1] 40000 コンテナを動かす SRE チームに至るまでの道

現在、私達の SRE チームは 40000 コンテナ以上のアプリケーションが稼働する PaaS 環境をヤフー株式会社内向けに本番提供しています。 社内で本番利用され始めてから 3年近くが経ちましたが、その過程で PaaS SRE チームは様々な困難に遭遇しました。 本発表では、PaaS SRE チームが、1. どのようにアラートに立ち向かい、安定性を保ったのか、2. どのように目標と向き合いユーザとの関係を築いたのか、3. スクラムを実践したのか、について共有します。

13:20~13:40

[B1] タクシーxAIを支えるKubernetesとAIデータパイプラインの信頼性の取り組みについて

AIを使ったオートモーティブ領域のサービスとして、タクシー営業を最適化するお客様探索ナビを開発しています。 データサイエンティスト、ドメインアルゴリズムエンジニアが開発した結果を、MLOps、サーバサイドエンジニアがデータパイプラインとサーバAPIとして構築し、最終的にタクシー乗務員向けの最適走行ナビアプリとして提供しています。 このアーキテクチャの信頼性に対する取り組みとして、データパイプライン中でタクシー運行シミュレーションによる評価行ったり、API末端で案内経路に異常が発生していないか、交通規制を守って走行できるかのチェックなど、複数の施策を行っています。 スコープをアーキテクチャの信頼性にしぼり、データパイプラインとアーキテクチャの全体像をお話した後、信頼性を担保するために、行っている施策とそれを取り組むに至った考え方を紹介します。

13:20~13:40

[C1] 絶え間なく変化するメルカリ・メルペイにおけるSREの組織と成長

現在メルカリ・メルペイ両社は絶え間ない変化の最中にいます。メルカリにおいてはマイクロサービス化が本格的に進展した一方、メルペイでは2019年のプロダクトリリース前後における怒涛の開発、そしてそれに伴い生じたの諸課題への対応など…。 本セッションではメルカリ・メルペイ両社におけるSREチームのEngineering Managerより、そういった激しい変化の中でどのようにSREのプラクティスを浸透させたか、そのためにどのようなチーム作りを行ってきたかについての生の事例をご紹介できればと考えています。

13:20~13:40

休憩

13:50~14:10

[A2] パフォーマンスを最大化するための SRE のオンボーディング事例

「オンボーディングとは、組織やサービスに新たに加入した人に手ほどきを行い、慣れさせること。」です（IT用語辞典より引用）。 本セッションでは、新しく入社した人にパフォーマンスを最大限発揮してもらうために、どのようなオンボーディングをしているか、事例を紹介します。 オンボーディングをする過程で、どのようなことに問題を感じ、改善したのお話しします。 一般的な話しも含まれるかもしれませんが、可能な限り SRE のためのオンボーディングについてお話ししたいと思います。 以下が予定しているアウトラインです。 ・今までのオンボーディングにおける課題 ・オンボーディング改善のモチベーション ・オンボーディングの事例 ・チームとしての取り組み ・今後の展望

13:50~14:10

[B2] 計画的に負荷リスクを排除するためのキャパシティプランニング

自分たちのシステムのキャパシティが把握できておらず、サービス運用の中で負荷的なリスクが見えないため事業判断がしづらいという課題がありました。 実際に、施策リリースの影響で負荷が高騰してしまいサービスのエラーレートが高い状態が長時間続いてしまったことがあり、新規施策が安心してリリースしづらいという状態になっていました。 その課題に対して、定期的な負荷試験によるシステムキャパシティの把握と試験結果をサービス運用に活用する動きをしてきたので、その中で得られたプラクティスを共有できればと思います。 大きく分けて負荷試験の運用、試験結果をサービス運用にどう活用しているかについてお話しする予定です。

13:50~14:10

[C2] 成長を続ける広告配信プラットフォームのモニタリングを改善してきた話

VOYAGE GROUP の中で広告配信プラットフォーム（SSP）を提供している fluct のモニタリングの歴史について。 事業成長し変化していく環境の中でどのようにモニタリングを変えてきたのか、提供しているサービスの特性を踏まえて紹介します。 その中でも、何を課題に感じて変えようと思ったのか、何故そのツールを選んだのか、アラート通知はどうしているのか、といったことにフォーカスします。

13:50~14:10

休憩

14:25~14:45

[A3] freee のエンジニアは障害から何を学び、どう改善しているのか？

Fintech の枠を超え社会インフラになりつつある freee のプロダクトですが、残念ながら障害はゼロではありません。想定外の障害もあれば、単純なオペミスによる障害もあります。ですが freee のエンジニアは障害から学びを得て、常に改善を繰り返しています。 個人の失敗を責めても何も始まりません。失敗を許容する文化を根付かせ、失敗から学ぶ文化をどう育てるか？ このセッションでは freee で実際に取り組んでいる障害からの学びと改善策をご紹介します。

14:25~14:45

[B3] グループウォレットアプリ、6gramの運用をはじめてみた

ミクシィは、みんなで使えるグループウォレットアプリ「6gram」を2019年11月にリリースしました。 6gramでは、JCBバーチャルプリペイドカードの発行やApple Pay/Google Payと連携したQUICPay+によるモバイル決済の提供を行っており、バックエンドでは決済ネットワークとのやりとりから精算システムに至るまで、そのほとんどすべてをフルスクラッチで実装しています。 少人数のチームでPCIDSSに完全準拠したシステムの開発と運用を行っていくために、我々が採用した構成や開発手法などについて具体的にお話します。また運用中の異変を素早く検知する機構の整備など安定した決済サービスを提供するための取り組みについても合わせて紹介します。

14:25~14:45

[C3] delyにおける安定性とアジリティ両立に向けたアプローチ

SRE本には「第Ⅱ部 9章 単純さ」という章があり、その中にこのような一文があります。 > システム管理に対するSREのアプローチをうまくまとめるなら「要するに、私たちの仕事はシステム内でのアジリティと安定性のバランスを取ることなのです」 「安定性とアジリティのバランスを取ること」はSREの重要な役割であり、圧倒的な変化やスピードが求められるdelyにおいては特に重要な役割だと考えています。バランスをとるための分かりやすい手段としてエラーバジェットがありますが、エラーバジェット自体はシンプルな考え方でありSREの本質でありつつも、仕組み上組織への導入はかなり難易度が高いものになっています。将来的にエラーバジェットを導入することを目標としても、まず大前提として組織としての考え方を変えていく必要があると考えます。 本セッションでは、組織としての考え方を変えていくために、SREとして、マネージャとして何を行ってきたのか、技術だけでは解決できないことに対してどういった工夫を行ってきたのか、などを話したいと思います。

14:25~14:45

[D3] Practices for Making Alerts Actionable

SRE本におけるページャーを鳴らす基準の一つとして「アクション可能であること」が挙げられています。 グリーの提供する100を超えるサービスの監視システムでは日々多くのアラートが発報されていますが、中には対応が不明確であり、具体的な復旧アクションを必要としないものも存在していました。 本セッションではそういったアラート対応を削減、自動化、またはアクション可能なものへと変えていく方法について具体的な事例と共に紹介します。

15:00~15:20

[A4] 日経電子版SREチーム立ち上げ中

日経電子版を支えるSREチームが2019/1に発足しました。メディアとして安定したサービスを実現し、いつでもニュースをユーザーに届けられるようにすることは重要だと考えています。しかし、開発チームの体制は電子版を構成するシステムごとに分かれており、電子版全体の可用性、信頼性、アーキテクチャに責任を負うチームはありませんでした。また、各開発チームは機能開発と可用性、信頼性の担保の両方の責務を負っていて、必ずしも安定稼働上の課題に注力できない環境にあります。この課題を解決するべく、SREチームを発足しました。まだ、道半ばではありますがこれまでの取組を共有します。

15:00~15:20

[B4] 冗長性と生産性を高めるハイブリッドクラウド環境の実現

株式会社ユーザベースのコアプロダクトである SPEEDA を支えているハイブリッドクラウド環境。元々はオンプレミスのみで構成されていた環境から、パブリッククラウドである GCP とオンプレミスのハイブリッドクラウド環境への拡張を行いました。どのようにしてハイブリッドクラウド環境への拡張を行ったか。そこに至るまでの軌跡とこれから目指すべき姿をお話いたします。また、オンプレミス→ハイブリッドクラウド環境への拡張を行う上で発生した課題と解決までの道のりや、冗長性と生産性を高めるための工夫についてもお話いたします。 ・GCP : Dedicated Interconnect の活用 　- Shared VPC の活用 ・GCP : Cloud VPN を活用した冗長 ・GCP : Cloud DNS を用いたハイブリッドクラウド環境における名前解決 ・Kubernetes + Istio を用いたインフラの抽象化

15:00~15:20

[C4] SLO Review

プロダクト開発に関わるすべてのひとのための共通目標であるSLO、うまく運用できていますか？1st SRE Book の登場後、SLO・エラーバジェットという考え方自体は広がってきていますが、それを実際に日常の運用に落とし込むためには工夫が必要です。SLO Review を行うことが本当に Product の信頼性につながるのか、本当にやるべきことなのかを確かめるために、最初は SRE である私が1人ではじめ、それが良い習慣であることを確信した後、チーム全体に展開しました。本発表では、まずSLOを定期的に実施する「SLO Review」を SRE だけでなく Web Developer, Business Developer を含む Product Team へどのように浸透させていったのか、その具体的な方法を説明します。後半では Datadog を用いて SLO Review を具体的にどうやって行うのか、それを行うことでどのような利点があるのか、なぜそれが良い習慣であるのかについて説明します。

15:00~15:20

[D4] 100万回線のIoT通信を支えるソラコムにおけるOpsDevの実践

ソラコムでは130を超える国と地域で利用できるIoT向け通信プラットフォームをAWS上で開発・運用しています。本セッションでは高い信頼性が求められる通信プラットフォームの安定稼働の実現のためソラコムの運用チームが行なっている活動について紹介します。具体的には、開発チームと共に行っているシステム設計やグローバルに展開する通信プラットフォームのモニタリング方法、サポートチームと連携したトラブルシューティングや運用チームが大事にしているカルチャーについてご紹介させていただきます。

15:30~15:50

[A5] 急成長するPairsと共に変化・成長し続けてきたエウレカのSRE戦略

私たちが開発・運用してきた恋愛・婚活マッチングサービス「Pairs」は ここ数年にわたり、毎年140%以上の成長をし続けて、2019年には日本・台湾・韓国で会員数が1000万人を突破しました。 サービスの成長が加速し続ける一方で、機能・管理対象の増加、システムの負荷やリソース、可視性の向上の必要性 管理コストの増加などなど、様々な課題を解決・改善し続けて、システムもエンジニアも成長していく必要がありました。 今回は成長し続けるサービスの品質を守るために、またサービスの成長を阻害せず開発を加速する為に、どのような戦略や指標を持ってエウレカのSREチームや開発チームのエンジニアが、システムや行動を変化させてきたかを 具体的な取り組みをまじえつつお話しできたらと思います。

15:30~15:50

[B5] New RelicのSREに学ぶSREのためのNew Relic活用法

New RelicはSaaSで提供しているObservabilityプラットフォームで、日本でもすでにたくさんのSREの方に活用してもらっています。そんなNew Relicのサービス自体もSREがNew Relicを使って日々サービスの健全性を保ち、改善を行っています。 今日はNew RelicのSREが使っている事例を紹介しながら、SREの方のためのNew Relicの機能活用法を紹介したいと思います。

15:30~15:50

[C5] スクラムを1年回してSREと開発組織がどう変わったのか

我々ビズリーチ社のSREは 「Make It Visible」「No Ops, More Code」 というビジョンを掲げ、 Google SREのプラクティスを基に様々な活動を行っております。 SREの日々の業務は複雑で、難易度の高いものがほとんどです。やるべきことが多岐にわたったり、緊急度が高かったり、すぐにオンコールで対応しなければならないこともあります。また、プロダクトの成長に伴い、品質と開発スピードのバランスを取ることが課題として上がってきています。我々はれらの課題に対してスクラムを導入することで立ち向かっています。スクラムに取り組み、SREと開発組織がどう変わったのか、SREがスクラムを回すコツを事例や実際の取組みを通してご紹介します。

15:30~15:50

[D5] Blue-Green デプロイメントを採用したデプロイの仕組みを実装して共通基盤として導入した話

NTT Ltd. Group ではマイクロサービスアーキテクチャを採用したサービス開発を行っています。 当初、各マイクロサービスのデプロイ方式についても各サービス開発チームに一任していたため、様々な方式が乱立し、運用性の低下につながっていました。 GKEをベースとしたコンテナ基盤の導入を機にSREチームを結成し、共通基盤としてSpinnaker、Algo Rolloutの導入、Blue/Greenデプロイメントの実現、デプロイパイプラインのコードでの構成管理に取り組んでいます。 本セッションでは、その取組を進める中で直面した課題や解決策についてご紹介します。

16:05~16:45

[A6] SREがセキュアなWebシステムを構築、維持するためにやれることはなにか

セキュリティ専門のエンジニアが組織にいない場合、古くなったソフトウェアのメンテナンス、鍵の管理、ファイアウォールの管理を誰が行うのか。それが曖昧な状況が長く続くとサービスが脆弱となり、やがて問題を引き起こすことでしょう。 サービスとシステムの信頼性に対してSREが責任を持つ組織においては、SREが中心となってセキュリティの問題を把握し、安全で堅牢な状態を維持する必要があります。Webアプリケーションやクラウドを使ったシステムをセキュアに保つためにできることは多くあります。 新しくサービスを開発する時、サービスの規模が大きくなってきた時など、セキュリティを意識すべきフェーズで何をすべきなのか、戸惑うことは少なくありません。セキュアなWebシステムを構築、維持するために、最低限知っておきたい知識、応用的な事例について、今までの経験をもとにお話したいと思います。

16:05~16:45

[B6] ZOZO MLOps のチームリーディングとSRE(Engineering)

私は2019年4月にZOZOにMLOpsチームを作り、それから10ヶ月ほどチームをリードしてきました。 その10ヶ月の間にZOZOでは買収も含め色々なことがありましたが、MLOpsチームではZOZO画像検索のリリースを含め、数々のミッションを達成してきました。 本発表では、ミッションを達成できる良いチームを作るために、どのような指針をもって私がチームをリードしてきたのか話します。 また、MLOpsと通常のSRE(Engineer)に求められるスキルセットの違いについて述べ、実際に遭遇した問題を踏まえて、どのようにチームとしてSite Reliabilityを向上させてきたのか話します。 キーワード: ・システムのボトルネックを潰す ・プロジェクト進行上のボトルネックを潰す ・モチベーションコントロール ・心理的安全性 ・当たり前のレベルを引き上げる ・神は細部に宿る ・仮説と検証のサイクル

16:05~16:45

[C6] Designing fault-tolerant microservices with SRE and circuit breaker centric architecture

成長期のプロダクト開発において、新技術の導入やマイクロサービス化などの破壊的な変更を経験するケースがある。実際の現場ではこれらの破壊的な変更を本番環境に導入するにあたり、稼働中のサービスの可用性を維持しつつ、技術や開発体制再構築のプロセスが必要となってくる。このプロセスは組織によって異なるため、様々な事例が広く共有されることが望ましいと考えている。 クックパッドのグローバルサービスでも既存の検索サービスを進化させるために破壊的な変更を行った。具体的には、検索サービスを再開発するために開発メンバー、開発言語、インデックスの構築ロジックの変更、また内製の Machine Learning API との連携など、これまでの検索サービスにはない取り組みも行った。一方で、検索サービスは高い可用性が求められる。上述の破壊的な変更があるサービスを本番に投入する際もこれは例外ではない。 そこで、本セッションでは新サービスを既存サービスの可用性に影響を与えることなく本番導入するためのアーキテクチャ、開発規則(Design Docs や SLO の設定方法)、主要技術に関するノウハウを共有する。

16:05~16:45

休憩

16:55~17:35

[A7] サイト信頼性エンジニアリングの原則

サイト信頼性エンジニアリング（SRE）に出てくる原則や手法について、コンパクトに例を交えながら解説します。まだSREを導入を検討している方、導入しているけれど違和感を感じている方などに、SREがどのような原理で運用されているかを理解する一助になると思います。モニタリング、アラート、自動化、SLO、エラーバジェット、ディザスター耐性テスト、ポストモーテムなどのキーワードに興味がある方は是非お越しください。

16:55~17:35

[B7] SRE Practices in Mercari Microservices

Mercari Microservices Platform Team is building a platform for backend developers to develop and run microservices. Currently, in this platform, around 100+ microservices are running and more than 200+ developers are working. To run this scale of the platform, the reliability is really critical. In this talk, I will share how we operate the platform by applying Google SRE practice: how we set and update SLI/SLO, how we on-call, how we ensure observability and prepare playbook and so on.

16:55~17:35

[C7] 実践Observability

近年、Webサービスを提供する中で、Microservicesアーキテクチャに代表される分散アーキテクチャを採用するシステムが増加しています。その結果、システムの複雑性は増し、各システムがどう連携しているか把握することが難しくなっています。そこで登場したのが、Observabilityという概念です。今回の発表では、改めてObservabilityとは何か、なぜ必要なのか、について私の考えを発表します。また、発表の後半では私が普段利用しているIstio, Prometheus, kiali, jaegerといったソフトウェアを使ってどのようにObservabilityを高めているかお話させていただきます。

16:55~17:35

休憩

17:50~18:20

[A8] Webサービスを1日10回デプロイするための取り組み

カヤックが運営しているゲームユーザー向けのコミュニティサービスLobiでは、多い日では1日に10回程度のデプロイを行っています。 この頻度でデプロイを行うためには、デプロイ自体の高速化はもちろん、CIの高速化、サーバエンジニア以外でも実行できる仕組み、実行後の異変を素早く検知し、問題があった場合に安全にロールバックを行う仕組みなど、いろいろなものを整備する必要がありました。 それらを具体的にどのような取り組みによって実現しているのかをお話しします。 ・開発したデプロイツール stretcher / ecspresso ・Jenkins から CircleCI へ移行し CI を高速化 ・Rundeck による GUI でのタスク実行 ・Mackerel と Google カレンダーに履歴を記録 ・Slack bot によるPRレビューやデプロイの管理

17:50~18:20

基調講演サテライト会場

18:30~19:10

[A9] パネルディスカッション

特別企画として、スペシャルゲストを招いたパネルディスカッションを行います。事前に参加者アンケートで募ったいくつかの質問を当日取り上げながら、SREに関する様々なテーマを扱います！お楽しみに！

18:30~19:10

パネルディスカッションサテライト会場

19:10~19:15

Closing

19:30~21:30

懇親会