読者です 読者をやめる 読者になる 読者になる

critical alertのブログ

普段はサーバのお世話係をしています

SRE Tech Talks に行ってきました

SRE Tech Talks - connpass

7/25(月)に行われた SRE Tech Talks に行ってきました。

SRE という単語はメルカリさんの有名な記事(下記リンク参照)で初めて知りました。しかし実際にどのようなことを行っているのかあまりピンときていなかったので、具体的な話を聞きたかった。申し込み数がエライことになってましたが運良く当選しましたのでスライドや感想などを簡単にレポートにまとめます。

tech.mercari.com

各セッションタイトルはイベントのページから引用しました。

株式会社メルカリ - SRE 長野雅広 @kazeburo Hybrid Server Architecture

speakerdeck.com

  • メルカリにおけるSREとはシステムの問題点を発見して解決する、それによってサービスの信頼性を向上させる
  • 開発環境/デプロイツールの整備やミドルウェアの開発、運用などを行っている
  • JPとUSでサービス展開をしていてそれぞれJPはさくらインターネットの専用サーバ+クラウド、USはAWSオレゴンリージョンで運用中
  • アーキテクチャを同じ構成にするためにできるだけマネージドサービスを排除し、ミドルウェアで同じ構成を再現している
  • 「マネージドサービスを使ってアプリケーションの開発に専念する」という話があるがより高いレベルの信頼性をSREが提供する
  • ただしSREによる信頼性の提供が難しいものは積極的にマネージドサービスやクラウドサービスを活用していく

Q&A

  • ダウンタイムの積算とかどうやっていますか?良いツールはありますか?
  • マネージドにする部分としない部分って何かポリシーがありますか?
    • 競争力のあるものは自分で管理する
    • 例えばメールサーバなどは自分で管理するのは大変なのでサービスを使う

ビジネスのコアな部分に関してはSREチームがマネージドサービス以上の信頼性を確保していく、そのためにどのようなことを行っているかという話でした。 たしかにマネージドサービスを使わなければOS以下のインフラ部分はどこを使っても同じ構成にできますね。 アプリケーションコードの中でAWSだったらこの処理をする、とか分岐していくとたしかにキリがないと思うし複雑になっていく...。 マネージドサービスを使わない以上、自分達で面倒をみないといけない。だからこそのSREチームという印象でした。

スマートニュース株式会社 Manager of Site Reliability Engineering 尾形暢俊 - @nobu666 Introducing in-house PaaS

www.slideshare.net

  • SREチームは現在二人
  • 5つの開発チームに分かれていて、サービス開発をする Ads, News, Application という3チーム、それらサービスを横串で横断する Infomation Systems, Site Reliability Engineering という構成
    • Infomation Systemsというのはいわゆる社内インフラでした
  • やってることとしては
    • セキュリティの担保
    • 横断的なシステムの構築
    • 開発環境の整備
    • デプロイフローの整備、等
  • そしてタイトルにもある社内PaaSを作っている。(SPaaS / SmartNews PaaS)
  • そのSPaaSは AWS ECS と Terraform の薄い wrapper でDockerベースのアプリケーションを簡単にデプロイするのが目的
  • CLIベースのスクリプトも用意されていて開発者が扱いやすいものになっている

組織構成が紹介されていてSREがどのように関わっているかわかりやすかった。 SREは横断してサービスチームに関わっているというこのなのでサービスチームには専属でインフラを見る人はいないということですかね。 ECSはやはり単独で使おうとするとかゆいところに手が届かない感じなのか、補完するアプリケーションを開発しているところは多そうです。

株式会社はてな システム開発本部 システムプラットフォーム部 倉知 真太郎 @dekokun サービス信頼性向上のための事例紹介@はてな

speakerdeck.com

  • はてなではSREという肩書きは存在しなくてwebオペレーションエンジニアという職種
    • webオペレーションエンジニアはいわゆるインフラ担当(ops)
    • webアプリケーションエンジニアは開発担当(dev)
  • オライリーの Site Reliability Engineering を社内で輪読会を開催して読んでいる
  • サービスに関わり方はwebオペレーションエンジニアチームというのがあり、そこから各サービスに担当としてつく
  • 何か問題があればwebアプリケーションエンジニアと協力して様々な問題を解決していく
  • 毎週行われる社内勉強会でお互いの仕事内容を発表していくなどして相互理解の助けになっている

とても楽しそうに発表されていて良い職場という雰囲気が伝わってきました。 devもopsもサービスの成長が第一でそのためにお互い協力しあって問題解決にあたるという姿勢はほんとに大事。 実際にどういう問題があってどのようなオペレーションを行ったか実例を出しながらの解説なのでイメージが湧きやすかったです。

Wantedly株式会社 リードエンジニア 相川直視 @awakia 実践!マイクロサービス化

speakerdeck.com

  • 前職はgooglegoogleのSREと働いたこともある
  • googleではインフラは神のような存在
  • インフラに求められるもの
    • どんどん新しいサービスを提供したい
    • 開発効率上げるために言語やアーキテクチャを選びたい
    • 少数チームでやりたい。既存より新規のほうが大変
  • サイトの信頼性担保が目標。googleだと規模がとても大きいのでそれをやるだけのチーム(SRE)がある
  • devはサイトの成長が目的
  • SREはエンジニアの生産性向上が目的
  • coreOS採用し、セキュリティアップデートが楽になった
  • APIゲートウェイを作って裏は全部APIでやってる
  • いいapiを作る
    • heroku api design,facebook apiを参考に
    • バージョンはヘッダで管理
    • ページネーションもヘッダに
    • リソースのネストは /users/:id/posts のレベルまで
  • batch apiという考え方
  • APIドキュメント
    • API blueprintをよさそう
    • json schemaは読みにくくてメンテ大変
    • swaggerはマイクロサービスでは高性能すぎる
  • Dredd でエンドポイントのテストもできる
  • Go でwebmockテスト書くのは大変
  • apiの価値を上げる
  • apiを作りやすくする

Q&A

  • SREの採用って難しくないですか?
    • SREという職種で募集しているが名指しでくる人は少ない
    • 本気で採用したいとなるとエンジニアの紹介ベースで採用するのが良さそう

どんどん新しいサービスを提供したい、言語やアーキテクチャを選びたいなど、様々な要求のなかインフラチームはどうやって動いてきたかという話。 マイクロサービス化することによってそれらの要求に応えようとしている。全てAPIで繋げてしまえばバックエンドの言語やアーキテクチャはなんでもよくなる。

単にDocker化したからマイクロサービスになるわけではなく、いいAPIを作るための土壌作りやテストを簡略にするツール、即座にインフラの立ち上げが可能になるDocker/Kubernetesの整備など具体的な解説を交えての解説でした。 ちょうど自分のチームのプロダクトでも React + Rails API で開発していてAPIまわりの話はとても興味深い内容でした。

まとめ

  • 各社それぞれどのようにサービスの信頼性を保っていってるか具体的な例もあってとても参考になった
  • SREの文脈から行くとソフトウェアエンジニア出身が多いよう(?)で運用も障害対応もやるけど目的達成のためにはバリバリコードも書きます、という感じ
  • コンテナ+サービスディスカバリーのような構成はやはり多い(ConsulやKubernetes,ECSなど)