Chatwork Creator's Note

ビジネスチャット「Chatwork」のエンジニアとデザイナーのブログです。

ビジネスチャット「Chatwork」のエンジニアとデザイナーのブログです。

読者になる

SRE部が発足しました

SRE

こんにちは。インフラマネジメント部 改め、SRE部のid:cw-tomita です。1月の組織変更で部署名の変更が行われました。せっかくの機会ですのでCreator's Noteで紹介したいと思います。

SRE(site reliability engineering)という言葉自体はエンジニアの方であれば結構知られているかと思いますし、また、様々な会社で既にSRE部/チームが発足していて、たくさんの紹介記事もありますので、"SREとは"みたいな所は以下のブログなどを参考にしていただければと思います。

インフラチーム改め Site Reliability Engineering (SRE) チームになりました - Mercari Engineering Blog

SRE チームを設立します - Cybozu Inside Out | サイボウズエンジニアのブログ

さて、SRE本*1 や↑の記事など、"SRE"という言葉にまつわる情報はたくさんあって、私も色々と読んだりしているものの、「SREって何？」って聞かれた時に、実は言葉で簡潔に説明出来ない*2ことに気が付いてしまいました。これからSRE部で働くのに、自分のミッションを説明できないということであり、とてもマズイ状況なので、改めて諸々の書籍/記事を読み直しつつ自分の中での考えをまとめてみました。

SREとmicroservicesとコンウェイの法則

システム開発/運用の世界を見渡してみると、ここ数年は、SREというトレンドに加えて、microservices化というトレンド*3があります。

microservicesアーキテクチャの文脈で、"resilient"や"high availability" というSREと関連がありそうな単語が一緒によく出てくること、また、この２つのトレンドが同時期に起こっているという所から、まず、最初の取っ掛かりとして、何かそこにヒントが隠されているのでは？？と思いました。 そして、この２つの関連をあれこれと調べて行く中で、昨年末までChatWorkで働いていたeverpeaceさんが、ChatWorkに入社される前に書かれた、こちらの記事*4に行き着きました。

マイクロサービス化が進む背景について考えてみた · GitHub

ここにコンウェイの法則に対する言及があり、この法則を思い出した時にピンとくるものを感じました。

コンウェイの法則

http://patterns-wg.fuka.info.waseda.ac.jp/japanplop/Translations/GDP/pattern14.htm

アーキテクチャは組織にしたがう。組織はアーキテクチャにしたがう。

"microservices"というアーキテクチャのトレンドに合わせて、"SRE"という、運用体制や組織体制のトレンドも同時的に発生している。これってまさしくコンウェイの法則では？？

組織におけるsidecarとしてのSRE

microservicesのシステム開発/運用では、一般的には各service毎に少人数のチームを構成します。このため、1つのservice = 1つのチーム で、コンウェイの法則がサクッとあてはまります。

では、1つのserviceの中におさまらないSREはどういう位置付けになるでしょうか？ 組織はアーキテクチャに従う という法則から逆引きで考えると、microservicesアーキテクチャの中にそのヒントがありそうです。そして、microservicesアーキテクチャの文脈でよく出てくるsidecarパターンのsidecarこそがSREの位置付けになるのでは？と思いました。

サイドカー パターン | Microsoft Docs

sidecarパターンでは、microservicesなシステムを運用するにあたって必要となってくる共通の機能(timeout, circuit breaker, 分散logging など)を各service毎に持たせるのではなく、各serviceが共通のproxyレイヤーを利用することで、各serviceはビジネスロジックにのみ集中できるようにする！ということを実現します。各serviceの開発スピードも上がりますし、proxyレイヤーに色んなノウハウを集中することでmicroservices全体としての安定運用に繋げることが出来ます。

これを組織に置き換えると、SRE部は、microservicesなシステムを運用するためのノウハウを有し、その機能を各serviceチームに提供することで、各serviceの開発者がビジネスロジックの開発に集中できるようになるためのsidecar的なチームと言えそうです。

具体的なタスクとしては、

  • Kubernetes cluster の管理、各serviceがKubernetesを使うためのサポート、Kubernetes内部で利用するsidecar proxyの選定/管理
  • Kubernetes以外の方法で動かしているアプリケーションのAWSインフラ全般、サーバ構築やデプロイメントの仕組み全般
    • 各serviceのチームにはビジネスロジックの開発に集中してもらって、各serviceをAWS上で安定的に出来るだけ安いコストで動かすという所はSREチームで実行する。広い意味で捉えると、こういうのもserviceに対するsidecarと言えそうです
  • EC2上にホストしているデータストア(Kafka, HBase)も守備範囲

といった辺りに取り組むことになります。

実際やることは、元のインフラマネジメント部時代からの延長部分が多く、「SREとは？」をあれこれ考えようが考えなかろうが、あまり変わらなかったかもしれませんが、"なぜ"それをやるのかと言った所に関して自分の中で腹落ちしましたし、長期的に見た時に、自分の部署のミッション/役割が明確になっているのは、とても大事なことと思います。

DBRE(Database Reliability Enginnering)

１点、先ほどのブロックで、

EC2上にホストしているデータストア(Kafka, HBase)も守備範囲

とさらっと書きましたが、 先に紹介したマイクロサービス化が進む背景について考えてみたの中では、

(DBAはチームごとに居ないと困る)

とありました。これは矛盾してしまっています。。

ここにはなぜ困るのか、詳細は記載されていないので、私なりの推測も交ざりますが、

  • データストアはserviceに密結合しているので、ここのownershipをserviceを担当するチームが直接持たずに、汎用的なチームが持ってしまうと、クエリやテーブルの追加/修正の度に、別チームへの承認が必要になり、開発スピードが低下しまう
  • また、それによって、"devops"から"dev(service開発チーム) vs ops(データストレージ管理チーム)" の図式に戻ってしまう懸念
  • (私自身、サービス開発者側の立場で↑のような環境で仕事をしたことありますが、色々とストレスはありました。。)

があるのではないかと思いました。

ただ、一方で、各serviceチーム毎に、都度データストレージの選定作業を行ったり、同じデータストレージを使っているserviceが複数あるのにオペレーションを完全に分けてしまうのは効率が悪そうですし、各チーム毎にDBAを雇えるかというと、予算的/人材獲得的なところで難しそうな気がして、現実的ではなさそうな気もします。

こういった問題への対処として、DBRE(Database Reliability Engineering)という概念が出てきています。

Database Reliability Engineering - O'Reilly Media

Surge 2015 - Laine Campbell - Database Reliability Engineering, Modernizing the DBA Role - YouTube

詳細な説明は上の書籍/プレゼンに定義されていますが、DBREのざっくりとした定義という所で、書籍の一章が以下に公開されていましたので、ここの抜粋を翻訳すると

1. Introducing Database Reliability Engineering - Database Reliability Engineering [Book]

・正しいplug-inを提供し、適切なメトリクスが収集できていることを保証する
・新しいデータストアを利用する際に、backup/recovery の機能を作る
・参考になるarchitectureとconfigurationを定義し、開発チームが利用可能な状態にする
・データのSecurity基準の定義作成を共に行う
・データベースの変更に際して、安全なデプロイ方法やtest用scriptを提供する


つまり、有効なDBREとは、(DBの管理を行えるように)他のチームを導いて権限を与えるように機能する存在であり、門番として機能するわけではないのです。

従来の"DBA"と"DBRE" の違いは、最後の一行に集約されている気がします。門番として自分たちが全ての責任を持つのではなくて、各serviceチームに権限を渡しつつ、同時に正しくデータストレージを扱えるように導いてくれる存在であると。確かにこういった役割を果たしてくれる存在がいたら、各serviceチームが、開発スピードを維持しつつ、権限を持って、適切にデータストレージ運用をしていけそうです。

"SRE"をmicroservicesにおけるsidecar的役割として説明しましたが、"DBRE"はデータストレージに特化した組織のsidecar的役割を果たす存在とも言えそうです。

現在のChatWorkの規模や、元々DBAという存在がいなかった状況を考えると、DBREという役割を導入するのはまだ早そうですが、サービスの成長速度を落とさずにスケールさせていくことを考えた時に、データストアをどうしていくかというのは根幹になる部分なので、こういったトレンドもしっかりと頭に入れつつ、組織もサービスも進化させ続けていきたいです。

まとめ

SRE部が新設されるにあたり、"SRE"という言葉を私なりに改めて考え直して自分たちの役割を整理しつつ、"DBRE"(Database Reliability Engineering)という概念の紹介もしてみました。 SRE部の紹介と言いつつ、今回の記事は概念的な話に終始してしまったので、、、次回以降の記事では、技術寄りの具体的な施策や取り組みなどを共有できればと思います。

ChatWorkでは、一緒にsidecarになりたい、microservices時代のSREを作り上げたい、DBREは任せろ！、というエンジニアを絶賛大募集中です！！

corp.chatwork.com

*1:https://www.oreilly.co.jp/books/9784873117911/

*2:SRE本ってめちゃくちゃ分厚いですよね...

*3:chatworkでの取り組みに関してはこちらのリンクを是非ご覧ください。 http://creators-note.chatwork.com/entry/2017/10/12/095636

*4:microservicesを独自の視点で説明されていてとても面白かったのでオススメです。