無印吉澤

ソフトウェア開発、運用管理(俗にいう DevOps)、クラウドコンピューティングなどについて、吉澤が調べたり試したことを書いていくブログです。

nginx.conf の location の優先順位を正しく理解する

f:id:muziyoshiz:20171026000347p:plain

最近、Nginx の location 設定の優先順位を誤解していて軽くつまづきました。このへん時々よくわからなくなるので、自分のためにまとめておきます。

情報源

公式の説明は、マニュアルの Module ngx_http_core_module ページ内の "location" の項にあります。

nginx.org

location の修飾子(modifier)

location を定義する際に使える修飾子は、以下の5種類です。

修飾子 判定方法
= 完全一致
なし 前方一致
^~ 前方一致
~* 正規表現(case-insensitive)
~ 正規表現(case-sensitive)

前方一致が2種類ありますが、これは「^~ は省略可能」という意味ではありません

location の優先順位

location の優先順位を考える上でややこしい点は、書かれた順に評価される設定と、最長一致で評価される設定が混在していることです。特に、優先順位をややこしくしているのが ^~ の存在です。

Nginx は、あるリクエスト URI に対する configuration を決めるために、以下の手順で location を選択します。

  1. 完全一致の location を判定し、マッチしたらその location を選んで終了
  2. 前方一致の location を判定し、最も長い文字列がマッチしたものを記録する(最も長い文字列がマッチした location が ^~ 修飾子を使っていた場合に限り、その location を選んで終了)
  3. 正規表現の location を、設定ファイルに書かれた順で判定し、最初にマッチしたものが見つかった時点で終了
  4. 3 でマッチするものが見つからなかった場合は、2 で見つかった location を選んで終了

ポイントは、^~ にマッチしたらその場で判定が終わるわけではない、ということです。^~ なしの前方一致のほうが最も長い文字列(longest matching prefix)の場合は、手順3の正規表現の判定に進んでしまう、という点に注意が必要です。

もしも ^~ 修飾子を全く使わなければ、以下のように簡単に優先順位を説明できます。

  1. 完全一致
  2. ~* または ~ 修飾子で定義された正規表現のうち、設定ファイルに書かれた順で最も最初にマッチしたもの
  3. 修飾子なしで定義された前方一致のうち、最も長い文字列がマッチしたもの

結局 location はどういう順に書いたらいいか?

個人的には読みやすさを考えて、評価される順(自分が評価してほしいと期待する順)に書いておくのがよいと思います。また、^~ ありの前方一致は混乱を招くため、^/ から始まる正規表現として書いてしまったほうがよいのではないか、と思います。

  1. 完全一致の location を書く
  2. 優先したい前方一致の location を、^/ から始まる正規表現の location として書く(^~ は使わない)
  3. 正規表現の location を、優先したいものから順に書く
  4. 修飾子なしの前方一致の location を、長いものから順に書く

Nginx のマニュアルに書かれた location の例を微修正して、上のルールに従って書き直したものがこちらです。

# ルートへの完全一致
location = / {
    [ configuration A ]
}

# /images/ 以下の画像
location ~ ^/images/ {
    [ configuration D ]
}

# /images/ 以外に置かれた画像
location ~* \.(gif|jpg|jpeg)$ {
    [ configuration E ]
}

# /documents/ 以下のページ
location /documents/ {
    [ configuration C ]
}

# その他すべてのページ
location / {
    [ configuration B ]
}

まとめ

おそらくですが、適当な順序で location を書いてしまってもなんとなくそれなりに動くように、こういう仕様になっているのではないか、と思います。とはいえ、このへんを正確に理解しておかないと、他の人が書いた nginx.conf をいじるときにつまづきやすいので気をつけましょう。

参考ページ

location に関する説明を色々探してみて、このブログの記載が一番わかりやすくて参考になりました。

paulownia.hatenablog.com

おまけ:location の説明の日本語訳

以下、マニュアルの該当箇所の日本語訳です。古いバージョンの Nginx について書かれた記載や、特殊なケース(macOS など)について書かれたケースは割愛しました。

Sets configuration depending on a request URI.

location はリクエスト URI に応じて configuration を設定する。

The matching is performed against a normalized URI, after decoding the text encoded in the “%XX” form, resolving references to relative path components “.” and “..”, and possible compression of two or more adjacent slashes into a single slash.

マッチングは正規化された URI に対して実施される。正規化とは、"%XX" 形式でエンコードされたテキストのデコード、相対パスを表すコンポーネント "." および ".." への参照の解決、そして2つ以上の隣接したスラッシュの1個のスラッシュへの圧縮である。

A location can either be defined by a prefix string, or by a regular expression. Regular expressions are specified with the preceding “~*” modifier (for case-insensitive matching), or the “~” modifier (for case-sensitive matching). To find location matching a given request, nginx first checks locations defined using the prefix strings (prefix locations). Among them, the location with the longest matching prefix is selected and remembered. Then regular expressions are checked, in the order of their appearance in the configuration file. The search of regular expressions terminates on the first match, and the corresponding configuration is used. If no match with a regular expression is found then the configuration of the prefix location remembered earlier is used.

location は prefix string または正規表現で定義できる。 正規表現は "~*" 修飾子(case-insensitive なマッチング)、または "~" 修飾子(case-sensitive なマッチング)で指定される。 与えられたマッチする location を探すために、nginx は最初に prex strings (prefix locations) を使って定義された location をチェックする。 そのチェックの間に、最も長い prefix とマッチした location が選ばれて記録される。 その次に正規表現が、設定ファイルの中で登場した位置の順にチェックされる。 正規表現の検索は、最初にマッチした段階で終了して、その location に書かれた configuration が使われる。 もし、そのリクエスト URL にマッチする正規表現が見つからなかった場合は、その前の段階で記録された prefix location の configuration が使われる。

location blocks can be nested, with some exceptions mentioned below.

location ブロックはネスト可能である。ただし、以下に示すいくつかの例外がある。

Regular expressions can contain captures (0.7.40) that can later be used in other directives.

正規表現は captures を含むことができる(0.7.40)。これは後の directives で使うことができる。

If the longest matching prefix location has the “^~” modifier then regular expressions are not checked.

もし、longest matching prefix location が "^~" 修飾子を持っていたら、正規表現はチェックされない。

Also, using the “=” modifier it is possible to define an exact match of URI and location. If an exact match is found, the search terminates. For example, if a “/” request happens frequently, defining “location = /” will speed up the processing of these requests, as search terminates right after the first comparison. Such a location cannot obviously contain nested locations.

また、"=" 修飾子 を使うと、URI と location の完全一致を定義できる。 もし、完全一致が見つかったら、location の検索は終了する。例えば、もし "/" へのリクエストが頻繁に起こるなら、location = / を定義することでそれらのリクエストの処理を高速化できる。検索は最初の比較で完了するからである。そのような location が、ネストされた location を持つことは明らかにできない。

Let’s illustrate the above by an example:

上記のことを、例を使って説明しよう。

location = / {
    [ configuration A ]
}

location / {
    [ configuration B ]
}

location /documents/ {
    [ configuration C ]
}

location ^~ /images/ {
    [ configuration D ]
}

location ~* \.(gif|jpg|jpeg)$ {
    [ configuration E ]
}

The “/” request will match configuration A, the “/index.html” request will match configuration B, the “/documents/document.html” request will match configuration C, the “/images/1.gif” request will match configuration D, and the “/documents/1.jpg” request will match configuration E.

/ へのリクエストは configuration A にマッチする。"/index.html" へのリクエストは B にマッチし、"/documents/document.html" は C にマッチする。"images/1.gif" は D にマッチし、"/documents/1.jpg" は E にマッチする。

The “@” prefix defines a named location. Such a location is not used for a regular request processing, but instead used for request redirection. They cannot be nested, and cannot contain nested locations.

"@" 前置詞は名前付きの location を定義する。そのような location は正規表現の処理には使われないが、リクエストのリダイレクトのために使われる。"@" 付きの location はネストできないし、ネストされた location を含むこともできない。

If a location is defined by a prefix string that ends with the slash character, and requests are processed by one of proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass, or grpc_pass, then the special processing is performed. In response to a request with URI equal to this string, but without the trailing slash, a permanent redirect with the code 301 will be returned to the requested URI with the slash appended. If this is not desired, an exact match of the URI and location could be defined like this:

もし、location が、/ で終了する prefix string によって定義された場合、リクエストは proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass, または grpc_pass のうちの1つによって処理されて、その特別な処理が実行される。 この文字列に一致する URI を持つリクエスト、しかし末尾に / が付かない URI の場合は、その URI に対する恒久的なリダイレクトが、/ 付きの URI に対して返される。 もし、その動作が望ましくない場合、URI と location の完全一致を以下のように定義すればよい。

location /user/ {
    proxy_pass http://user.example.com;
}

location = /user {
    proxy_pass http://login.example.com;
}

Mercari Meetup for Microservices Platform #2 参加レポート

f:id:muziyoshiz:20190527230059p:plain

メルカリの Microservices Platform Team のメンバによる技術イベント Mercari Meetup for Microservices Platform #2 に参加してきました。

connpass.com

どの講演も非常に面白くて、参考になりました。特に @spesnova さんによるマイクロサービスとその監視の事例は、このレベルを目指して頑張りたいと思える内容でした。

今回は、個人的に興味深かった部分中心のメモです。プレゼン資料が公開されていない部分などは、多少ミスもあると思います。そこはご了承ください(訂正情報いただいたら直します)。

Introduction & Attention

(スライドは未公開。タイトルは Connpass ページに掲載のもの)

Microservices Platform Team の Engineering Manager @masartz さんによる導入。

  • Mercari Microservices Platform Team の紹介
    • マネージャ1名とエンジニア8名の計9名
    • Mercari と Merpay 両方のサービスが乗るプラットフォームを作っている
    • 新しい分野に対してチャレンジングな仕事をしている
    • Observatoryといった数値を大事にして、いろいろな取り組みをしようとしている
    • 自分たちで仕組みを改善していっている
  • Merpay SRE の紹介
    • マネージャ1名と SRE 3名の計4名
    • Merpay の安定性と信頼性を支える
    • Mercari はモノリスからマイクロサービスに置き換えるというチャレンジをしているが、Merpay は最初からマイクロサービスで作る、というまた別のチャレンジをしている

Kubernetes Cluster Monitoring

Microservices Platform Team の @spesnova さんによる、Kubernetes クラスタの監視についての講演。

Kubernetes クラスタの監視について非常に細かく解説されており、勉強になりました。

  • Monitoring kubernetes cluster
    • Microservices Platform Team はクラスタ自体の監視をする(その上のアプリ監視の話ではなくて)
    • 何を持ってクラスタが正常かどうかを確認しているか?
  • マイクロサービスの規模
    • Kubernetes クラスタ上に、
      • マイクロサービス 100+
      • Pod 2K+
      • コンテナ 2K+
      • マイクロサービスを開発するエンジニア 200+
    • 会社全体で Kubernetes クラスタは1個ではない
    • Microservices Platform Team が見てないクラスタはまだたくさんある
    • メルカリ全体ではコンテナ 13k くらい?
  • Platform チームと developerの責任分界点(boundary)
    • Pods より上は developer
    • Pods より下は Platform チーム
      • Kubernetes master は GKE の管理下
      • Kubernetes nodes は GKE の管理下ではない。これはどこのクラウドでもそのはず
  • メトリクスの設計
    • RED and USE method
    • これの別表現で Work and Resource という言い方があり、両方の言い方を使っている
  • The Work (RED) metrics
    • システムが動いているか壊れているかを教えてくれるメトリクス
    • Throughput, Success, Error, Performance
    • Work のほうの Error は、レスポンスのエラーレートとか
  • The Resource (USE) metrics
    • 内部のメトリクス。low-level healthを教えてくれる
    • Utilization, Saturation, Errors, Availability
    • 例:swapを使ってる=どれくらい足りてないか=Saturation
    • Resource のほうの Errors は、バックエンドのサービスのエラーレートとか
  • Kubernetes クラスタの生死をどうやって監視する?
    • クラスタにとっての Work メトリクス=orchestrating できてるかどうか
      • Ready な Pod の数
      • Unavailable な Pod の数
      • Deployment ごとの Pods など、もっと細かい切り口でのメトリクス
    • Unavailable な pod がない=クラスタが orchestration の仕事をしている
    • ただ、unavailable な pod があっても、クラスタのせいとは限らない(開発者の設定ミス、GKEの障害など)
      • そのため、パーセンテージでアラートを出している。しきい値は緩めにしている
      • オオカミ少年にならないように
    • Master Components, Node Components, Addons の分類
  • 使っているツール
    • Cluster-level monitoring = prometheus
    • Cluster-level logging = fluentd とか
    • Stackdriver と Datadog
  • Work metrics の実例
    • メトリクスは Datadog で可視化している。Datadog のスクリーンショットを使いながら解説
    • GKE の障害は、僕らではどうしようもないので、神経質に見ない(というようなことをなにか別の表現をしていたけど忘れた)
    • kubelet runtime error rate を見ている。しきい値は緩めに設定
    • kube-proxy work metrics は可視化しているが、prometheusとの連携がうまくなくて?あまり使い物にならない。今後の課題
  • Resource metrics の実例
    • CPU, disk, memory, network など
    • クラスタ単位、ノード単位のダッシュボードもある
  • ダッシュボード
    • SRE と application engineer の間で、監視の boundary を決める
    • Work metrics と Resource metrics を意識してダッシュボードを作る(Work と Resource のダッシュボードは別)
    • Kubernetes のクラスタは分散システムなので、1箇所だけ見れば良いということはなく、Work と Resource を区別していろいろなダッシュボードを作って監視する必要がある

Securing Microservices Continuous Delivery using Grafeas and Kritis

Microservices Platform Team の @vbanthia_ さんによる、CI/CD へのポリシーの強制方法についての講演。

  • code > build > test > deploy といったワークフローの各段階で、ガバナンスを保ちたい
    • この機能をデプロイしてよいか
    • 脆弱性対応が済んでいるか(例:cpu.fail
  • ガバナンスを保つためには、従来はいろいろな CI/CD ツールを組み合わせてワークフローを実装する必要があった
    • いろいろなツールを組み合わせると、各フェーズをまたぐときにメタデータが失われてしまう
  • Grafeas(グラフィアス)は、中央集中型の汎用的なメタデータ管理サーバ
    • オープンな artifact metadata API を通して、任意のツールからメタデータを登録できる
  • Kritis はポリシーを強制するためのツール
    • Platform チームでは GCP と Spinnaker を使っている
    • 公式の Kritis はまだ early stage で、メルカリで必要な機能が未実装
    • そのため、Kritis を fork して機能拡張したものを使っている
    • QA → PM の順に承認を得て、承認を得た docker image だけが production cluster にデプロイされる

How We Structure Our Work At Mercari Microservices Platform Team

Microservices Platform Team の @deeeet さんによる講演。

Platform チームができてから2年位経つそうなのですが、そのなかでのプロジェクト管理方法の変遷についてのお話でした。

  • Platform チームにおけるプロジェクトマネジメント
    • 特殊なことをしているわけではない。一般的なWeb開発と変わらない
    • チームとしてのアウトプットを最大化する=開発者の生産性を最大化する=よりよいプロダクトをMercariの顧客により早く提供する
    • プロジェクトマネジメントのやり方を、チーム自身で継続的に改善している
  • 歴史
    • 最初は deeeet さん1人だった
    • 5名までは "No project management"
    • 8名までは (lightweight) Agile
    • 9名になった現在は 6 Week Release Cycle を採用している。今日は主にこれを紹介する
  • No project management
    • 単純な四半期のマイルストーンしかなかった
    • 各人が課題を見つけて取り組んでいた
    • 基本的に個人プレイで、チームではなかった。個人でやりたいことやっていた
    • マイルストーンにはやりたいことが詰まっていて、手元のタスクが進まなかった
    • ドキュメント整備、自動化が進まなかった。開発者に対するサポート業務に時間が取られていた
    • この経験からの学び:個人でできることには限界がある。チームとして動く必要がある
  • (lightweight) Agile
    • 2週間のスプリント、カンバン、スクラムマスター
    • 採用したのは、業界のデファクトだから。プロジェクト管理を始めなきゃ、という課題意識から始めた
    • 50%はプロアクティブなタスク、50%はリアクティブなタスクを取る、という取り組みを始めた(割合はGoogleを参考に)
    • 良くなかった点
      • ベロシティに集中してしまい、開発者に shipping しているという意識が遠のいた
      • Platform チームの仕事には2週間で区切れない仕事が多かった
      • 誰一人見積もりがうまくできなかった。見積もりが目的化する部分があった
    • 根本的に問題があるのでは?
      • アジャイルは仕様が決まることが前提で、ベロシティから作業量を予測する点が重要だと思う
      • 実際は、最初は不確定なことから始まる。基盤系は特にそうではないか?
    • アジャイルを極めるという選択肢もあったと思うが、自分たちは別の方向を模索し始めた

f:id:muziyoshiz:20190527230529p:plain
スライド中で出てきて面白かった図。不確定なうちは規模感がわからない

ReWork: Change the Way You Work Forever

ReWork: Change the Way You Work Forever

  • 6 Week Release Cycle の概要
    • 1回のリリースを6週間で区切る
      • この期間の長さは、だいたいどんな機能でも6週間あればリリースできる、というBasecampの経験則から
    • この期間にリリースする 1個の bic epic と、2〜3個程度の small epic を決める
    • 6週間すべて使うのが big epic
    • 1日〜2週間使うものが small epic
    • Big epic に 1 release team、small epic に 1 release team をアサインする
    • 1チームは2〜3名
    • 2つの原則
      • Dedicated resource allocation
        • Release team には与えられたエピックだけに集中してもらう
      • Fixed budget and flexible scope
        • 6 week + 2-3 membersというのは変えない
        • スコープは変えていい

f:id:muziyoshiz:20190527231011p:plain
6 Week Release Cycle

  • メルカリで追加した3番目の原則
    • Dedicated On Support Team
      • 開発者からのリクエストと、緊急の要件に対応するための、3番目の release team を作る
      • 時間があるときは技術的負債に対応する
  • ローテーション方法
    • 試行錯誤した結果、9名を3チームに分けて、release team (big epic)、release team (small epic)、support team をローテーションする方法に落ち着いた
    • daily や weekly のローテーションでは、release team にとっては開発期間として短く、support team にとっても開発者からのリクエストが完了しきらなかった

Merpay Microservices On Microservice Platform

メルペイ社にて Engineering Manager も担当している @tjun さんによる講演。メルペイ社のマイクロサービスの特徴と、その運用に関するお話でした。

メルペイ社のシステムは、メルカリのマイクロサービスとは傾向が違う部分が多少あるものの、共通の基盤に乗っているそうです。そのため、microservices-starter-kit や Datadog などの話は、メルカリにも共通する話、とのことでした。

  • メルペイのマイクロサービス
    • メルペイだけで40個以上のマイクロサービス
    • メルペイのマイクロサービスの特徴(世間一般、および Mercari との違い)
      • バッチ処理が多い(k8s上でバッチ処理をしている)
      • 外部パートナー(銀行など)との接続が多い
      • 開発者に対する権限を絞っている(セキュリティ、コンプラの関係上)
  • microservices-starter-kit
    • 新しくマイクロサービスを作るときは、Platform チームが作っている microserivces-starter-kit というものを使ってスタートする
    • サービス名やオーナー、開発者を定義して実行すると、GCP から Kubernetes まで、必要なリソースとその権限設定が自動的に作られる
    • Datadog のダッシュボードや PagerDuty のローテーションの設定まで、デフォルトのものが自動的に作られる(懇親会で聞いた話)
  • SLO and Alerts
    • 各開発チームに SLO を定義してもらっている
    • SLO は PM も参加して決めてもらう、などのルールを決めている
    • それぞれの SLO について Datadog monitor を設定している - RED metrics
    • Datadog で、各チームに SLOboard というものを作ってもらおうとしている
  • Datadog APM and Distributed Tracing with Go middlewares
    • 新しい開発者でもどこが遅くなっているか、などを見やすくしている
  • Incident handling
    • Datadog と Sentry でのアラートを、Slack や PagerDuty に送っている
    • 開発者が一次受けをしたあとで、アプリだけの問題ではない場合は SRE も一緒に問題を見る
    • 再発防止のため、インシデントのたびにインシデントレポートを作成する
  • メルペイの SRE の責任範囲
    • アプリケーションをまたがるインフラリソース
      • Ingress, CDN, キャパシティプランニング、セキュリティ
    • Production releases and operations
      • マイクロサービスの知見がないエンジニアも多いので、そこのサポート

感想

プレゼンのあとで、1時間近く懇親会の時間があり、細かい話を直接伺うことができたのはとても良かったです。

講演と、懇親会での話を合わせて、僕自身は Platform チームについて次のように理解しました。

  • Platform チームが見ている Kubernetes クラスタに関しては、かなりの部分がセルフサービス化されている(開発者だけでできるようになっている)
  • セルフサービス化のために、今回の講演で出てきた話(microservices-starter-kit のような自動化、Grafias/Kritis を使ったポリシー管理、開発者自身による監視の一次受け)を組み合わせている上に、ドキュメントの整備なども進めている
  • セルフサービス化が進んだことで、SRE がインフラ関係のコアな業務に集中できる状態になり、結果として Platform チームは9名という少人数で回っている

もちろん、現場ではいろいろ泥臭くて大変なことも多いとは思いますが、マイクロサービス化を推し進めた先の目指すべき理想形のイメージをつかめたような気がします。また同様のイベントがあったら是非参加してみたいです。

追記(2019-05-31)

Mercari Engineer Blog のなかで spesnova さんの資料も公開されていたので、リンク追加しました。

tech.mercari.com

SRE Lounge のスピンオフで、議論中心の新しい勉強会 "SRE Session" への誘い

f:id:muziyoshiz:20180927232609p:plain

SRE Session とは?

SRE Lounge のスピンオフで、SRE Session という勉強会の第1回が4月10日に開催されました。

sre-lounge.connpass.com

SRE Session は少人数かつ全員参加型で議論するタイプの勉強会です。当日は議論が盛り上がり、参加者の反応も良かったので、おそらく SRE Session #2 が6月頃に開催されそうです。そこで、だいぶ遅れましたけど(3週間近く経ってる……)軽く感想をメモしておきます。

SRE Lounge には何度か参加していて、SRE Session にもちょっと興味あるけど参加しようかどうしようか……という方の参考になればと思います。

イベントレポート

SRE Session #1 の内容については、すでに充実したレポートが書かれているので、こちらを読んでもらえると大体の雰囲気がわかると思います。

blog.chaspy.me

SRE Session の発起人 @chaspy_ さんのレポート。Session #1 の会場は Quipper Ltd. さまに提供いただいたのですが、こちらも chaspy さんにお世話いただきました。感謝しかない……。

qrunch.net

いつも SRE Lounge でお世話になっているスタッフの ktykogm (k-oguma) さんのレポート。Welcome talk の内容から、oguma さんが参加されたグループでの議論内容まで詳しくまとめてくださっています。

SRE Session のスタイル

ここから先は、主に SRE Session という勉強会のスタイルの紹介と、それに対する僕の感想です。一応、今回スタッフとして参加したのですが、椅子運びくらいしかしていないので、一参加者の感想として読んでもらえれば。

第1回はこういうスタイルでした(第2回以降で改善されて変わる可能性はあります)。

事前アンケート

connpass での申込時に、今回のテーマ(SLO と Monitoring)に関するアンケートを取りました。

  • SLOについて共有したい事例を記入してください
  • SLOについてディスカッションしてみたいテーマを記入してください
  • Monitoringについて共有したい事例を記入してください
  • Monitoringについてディスカッションしてみたいテーマを記入してください
  • その他この会に期待することを何でも教えてください

このアンケート結果は、スタッフが匿名化したうえで、事前に参加者全員に共有していました。今回、本編ではほとんど使わなかったですが、懇親会での話題のネタになっていました。

アンケートの記入は任意だったので、記入していたのは参加者の半分以下でした。ただ勉強会の性質上、議論のネタを持っている同士でないとつらいので、今後は記入必須になるかもです。

グループ分け

受付終了後に、いくつかのテーブルに散らばって座ってもらいました。

人数が少ないと議論が盛り上がりづらいため、3名のグループになってしまったところは他のグループに合流してもらい、最終的に4〜5名のグループを作りました。

f:id:muziyoshiz:20190429230359j:plain:w800

テーマごとのサイクル

SRE Session #1 は "SLO" と "Monitoring" の2テーマでした。このテーマごとに、以下の35分のサイクルを繰り返しました。

  • Welcome talk 10分
    • そのテーマに関する導入として、有識者の方のプレゼンを聞く
  • Discussion 20分
    • 軽く自己紹介をしてから、テーマについて思うことを話し合う
  • Sharing 5分
    • 各グループにマイクを回して、代表者1名が1〜2分で議論内容を紹介

Welcome talk

今回の Welcome talk は、Yahoo の tsuka さんと、メルカリの spesnova さんが担当してくれました。いずれも、このテーマだけで30分くらい話を聞きたいくらいの濃い内容でした。

こちらの welcome talk の詳しい内容について興味の湧いた方は、ぜひ上述のイベントレポートをご覧ください。

Discussion

Welcome talk のあとは議論の時間。

グループによって進め方はいろいろ違ったと思うのですが、僕たちのグループでは最初に自己紹介をしてから、welcome talk で出たキーワードを拾って、それぞれが興味あることを話した感じでした。

ちなみに、参加者全員が SRE だったわけではなく、例えば僕たちのグループの内訳はこんな感じ。

  • SRE 3名(自分含む)
    • ゲーム、アドテク、プロジェクト管理
  • バックエンド寄りの開発者 2名
    • うち1名の会社は、これから SRE を作ろうとしている段階

一言で SRE と言っても、サービスの種類や規模や、その人の組織内での SRE の立ち位置など、いろいろ違うところがあるので自己紹介は重要そう。

Sharing

最後に、司会が各グループにマイクを持って回って、グループの代表者が1〜2分で議論の内容を紹介しました。

内容のまとめ方は今回特に指定されなかったので、ホワイトボードを使うグループ、SRE Lounge の Slack に書いていくグループ、各人が手元にメモしていくグループ(僕のグループはこれでした)などいろいろでした。

懇親会

最後に、1時間ほど懇親会の時間がありました。

議論中心のイベントだけあって懇親会で帰る人はほとんどおらず、テーマに沿って話が盛り上がったあとだったので、普段の勉強会以上に議論が盛り上がったのではないかと思います(※個人の感想です)。

感想

普段、他社の SRE と深い議論をする機会ってあまり無いので、特定のテーマに沿ってじっくりと議論するのは楽しかったです。良い会だったと思います。

なお、chaspy さんが SRE Session のまとめ記事 に書いていますが、この会は Cloud Native Deep Dive というイベントのやり方にインスパイアされたものらしいです。今回の勉強会が楽しかったので、そちらにもいずれ参加してみたいです。

以下、次回以降どうするともっと盛り上がるかな……と考えたことのメモです。

時間の長さ

開催前は、2テーマは多すぎるのでは? 1テーマあたりの時間が短すぎないか?という議論もありました。

ただ、結果としては20分で少し足りないかちょうどよいくらいで、むしろこの倍の40分だったら場が保たずに辛かったかな、と思いました。

もう少し細かいテーマを設定すれば、もっと議論の時間が長くてもいいかもしれません。例えば、SLO のテーマであれば「組織内で SLO を決めるときに苦労していること」、「組織内で SLO をどのように、どれくらいの頻度で振り返るべきか」といったサブテーマをいくつか用意しておくとか……。

グループ分け

人数はこれくらいでよかったと思います。今回は5名上限でしたが、それ以上になると、1人あたりの話す時間が短くなりそうです。少なすぎても話に広がりがなくなるので、5〜6名がベスト?

あとは、参加者全員が SRE というわけではなかった(事前アンケートでそこまで聞いていなかったので当日気づいた)ので、グループ内に SRE の数が少ないと、その人の話を聞くだけになりそうです。

参加者が全員 SRE である必要はないと思いますけどね。個人的には、いずれ「SRE と開発者の関係」のようなテーマの回があってもいいんじゃないかと思っています。

とはいえ SRE の比率はある程度必要だと思うので、申込時に、SRE only 枠と自由枠で、募集枠を分けるとかしたほうがいいんでしょうか? そのうえで、各グループで SRE の比率が偏らないようにするとか?

議論のまとめ方

今回は特に指定がなかった部分ですが、これは事前に決めておいたほうがよかったかもしれません。

全グループの分だけホワイトボードを用意できる会場は多くないと思うので、ポストイットのイーゼルパッドを用意しておくとか。

あるいは HackMDCacoo のような(手前味噌ですみません)、リアルタイムに共同編集ができるサービスを使うようにお願いしておくとか決めておくと良いかも。議論の内容が電子的にまとまっていると、イベントレポートで共有したり、振り返るのも楽になりますしね。

参加者の総数

Sharing の時間は、元々5分の予定でしたが、実際は1グループあたり1分以上かかっていました。グループの数が多くなりすぎると、Sharing の時間が長くなってつらそうです。

そう考えると、参加者の総数としては6名×6グループ=36名くらいがちょうどいいあたりでしょうか?

参加者の総数をこれくらいに少なめに抑えておいたほうが、会場提供のハードルが下がっていいんじゃないか?と個人的には思っています。

SRE Lounge のほうはすっかり人気イベントになって参加希望者が多くなり、この規模の会場を提供できる会社さんは少なくなってきています。ちなみに、次回5月29日の SRE Lounge #9 は、募集開始から1日で150名の枠が埋まってしまいました(すごい!!)。

sre-lounge.connpass.com

SRE Session のほうは、それよりもっと小さい会場を転々とできるといいなあと。30名程度なら、議論に使える小さめの会議室いくつかと、Sharing の時間だけ集まるセミナールーム1室くらいでギリギリ開催できそうですし。具体的には、うちの会社の東京事務所でもギリギリ開催できそうですし。

SRE Lounge の Slack ワークスペースへのお誘い

SRE Lounge は特定のスポンサーとか特に付いていない、コミュニティベースの勉強会です。

イベント開催情報なども早めに展開されますので、もし SRE Session にご興味のある方はぜひ srelounge.slack.com にご参加ください! 特定のテーマで開催してほしい!もっとこういうスタイルで議論したい!という熱烈な希望があれば #sresession チャンネルでアピールしてもらえると採用されるかも?

SRE Lounge #8 の感想(取り入れたいと思った活動の話を中心に)

f:id:muziyoshiz:20180927232609p:plain

今週の水曜に、クックパッド社にて SRE Lounge #8 が開催されました。今回も参考になるお話が多かったです。

ちなみに、会場はキッチン付きの勉強会スペースで、さすがクックパッド!という感じでした。

ソラコムAPIの裏側で運用チームは何をやってきたのか

SORACOM の OpsDev Manager 五十嵐さん(インタビュー記事)による発表。

OpsDev というのは DevOps の書き間違いではありません。SORACOM では開発チームがメンテナンスと運用の両方に関わり、OpsDev チームは運用作業省力化のための開発をするチームとのことです。

OpsDev チームが開発したロングセラーツールとして、以下のものが紹介されていました。

  • 緊急時のみ SSH 接続を許可するための設定自動化
    • Slack に接続してきた開発者の IP アドレスを、Security Group に自動反映
    • CodeCommit に登録された公開鍵の、EC2 インスタンスへの自動配布
    • ログ取得(詳細は秘密でした)
  • PagerDuty に似た、電話での通知の仕組み
    • Slack で /tel ニックネーム とすると強制的に電話を鳴らす
  • 実際の移動体通信を監視するためのラズパイのタワー(ソラコム・サグラダ・ファミリア)

質疑応答の中で面白いと思ったのは、SORACOM の他の社員の方が「SORACOM ではエンジニアが開発、運用、サポートまで見るので、サポートが一人負けするようなシステムにはならない」と言っていたこと。開発と運用が一体なのは当たり前、という感じで、素直にうらやましいと思いました(個人的にはいつも悩んでいるところなので……)。ただ、基本的に開発者向けのサービスだからできる話かもしれません。

「開発チームの中に開発担当と運用担当ができてしまうのでは?」という鋭い質問もありましたが、「まだ、両者を分けられるほどエンジニアの人数がいない。開発した人が一番早く直せるというポリシーでやっている」とのことでした。

Cookpad Microservice Architecture Overview

クックパッドの技術部 SRE グループの吉川さん(@rrreeeyyy)による発表。

2013年頃からマイクロサービス化に取り組んできて、一進一退しつつ進んできたという話でした。開発者との恊働の話がいくつか出てきました。

例えば、今までは大統一 Terraform を作っていたが、これだと開発者にとってはプルリクを投げづらい。今後はチームごとにディレクトリを分けて、そのディレクトリ内の変更はチームの責任で実施できるようにしたいと思っている、など。

各サービスのチームを巻き込んだ SLI/SLO の導入はまだこれからで、今後の課題とのことでした。

最近、既存サービスのマイクロサービス化について悩んでいたので、懇親会でマイクロサービス化の良い進め方について相談しました。以下はそのときのメモです。

  • モノリシックなサービスの一部をマイクロサービスとして切り出したいとしても、最初は新しいサービスでマイクロサービスの作り方を確立して、開発者自身が自信を付けてからにするのがいい
  • データの切れ目でサービスを分割するといい。例えばクックパッドなら、レシピのデータとユーザのデータは別のもの(レシピの作成者としてユーザ ID が入る程度)なので、そこで分割するとか
  • 作業が SRE だけでほぼ完結するから、データベースの分割からやるのがやりやすいかもしれない。データベースをレプリケーションして、あるタイミングで writer をバタンと切り替える

ちなみに、マイクロサービス化は開発者のほうがモチベーションが高く、運用側から説き伏せて、みたいなことは全然なかったそうです。

割れ窓理論をWebインフラの改善に活用し、チーム内の知識共有を促進している話

はてなの id:hokkai7go さんによる発表。プレゼン資料に加えて、以下のブログ記事で詳細が補足されていました。

blog.hokkai7go.jp

10名程度のはてな SREs(共通基盤)チームで実施中の活動で、以下のようにやっているそうです。

  • 割れ窓(技術的負債)を見つけたら issue を作成して記録
  • 取り組みやすそうな issue を「週刊割れ窓マガジン」という記事にリストアップ
  • 週に一度、1時間の作業時間を取る(2時間だとダレた。現在は1.5時間に伸ばす試みをしてる)
  • 振り返りやすいよう、終わった issue はスプレッドシートで一覧にしておく

僕は勝手に、開発者も入ってる活動なのかな……と思いながら聞いてたのですが、SRE だけでやっている活動とのこと。最低でもチームの半分くらいは集まって実施するそうです。

SRE の活動のなかで、SLO には現れないけど重要な、運用の品質とでも言うべきものはあると思っていて、最近こういうブログ記事を書いたりしてました。

muziyoshiz.hatenablog.com

はてなの他の取り組みで、PWG(Performance Working Group)という活動も以前聞いたことがあって、自社でも少し実施し始めています。この PWG と併せて、割れ窓タイムも導入してみたいと思いました。

次回の SRE Lounge

次回は5月に、サイバーエージェントで開催予定とのことです。

また、SRE Lounge とは違う、特定のテーマに沿ったディスカッションの場として「SRE Session」というイベントが新たに企画されています。初回は 4/10 で、テーマは SLO と Monitoring です。テーマに興味のある方はこちらも是非どうぞ。

sre-lounge.connpass.com