こんにちは、ハートビーツの宮越と滝澤です。 2017年6月20日〜22日にサンノゼで開催されたO'Reilly Velocity Conference 2017 San Joseに参加してきました。
Velocity Conferenceは日本では馴染みがないカンファレンスですが、主に運用やSREやDevOps向けのイベントになります。
本記事では興味深かったセッションをいくつか紹介します。
なお、内容については紹介している資料を確認してください。聞き間違えたり、認識が違っているかもしれないためです。
コンテナ
Container orchestration wars
- スライド: Container Orchestration Wars (2017 Edition) (SlideShare)
MesosphereのKarl Isenberg氏によるContainer orchestrationの2017年時点でのまとめのセッションでした。 まとめの資料なので特にこれといったコメントはないのですが、ITインフラのプラットフォームの変遷もよくまとまっています。
(滝澤)
Observability in a dynamically scheduled world
- スライド: Observability in a dynamically scheduled world (PDF)
コンテナ分散システムの監視について。DigitalOceanではDOCC(Digital Ocean Command Center)というツールとKubernetes + Prometheus + Alertmanager でコンテナのデプロイおよび監視の自動連携をしているようです。資料には構成や設定方法、またハマり点やTipsが紹介されています。弊社では主にnagiosを使った監視を行っておりますが、Prometheusなど次世代の監視ツールと言われるものについても使いどころを把握し理解を深めていきたいと思います。
(宮越)
サーバレス
Serverless security: A pragmatic primer for builders and defenders
- スライド: Serverless Security: A pragmatic primer for builders and defenders (SlideShare)
Signal SciencesのJames Wickett氏によるサーバレスシステムのセキュリティについてのセッションでした。
最初に次のまとめを提示していました。
- Serverless encourages functions as deploy units, coupled with third party services that allow running end-to-end applications without worrying about system operation. （サーバレスシステムは、システム運用について心配することなくエンドツーエンドのアプリケーションを実行できるサードパーティのサービスを組み合わせて、デプロイユニットとしての機能を助長する。）
- New serverless patterns are just emerging （新しいサーバレスパターンが登場している）
- Security with serverless is easier （サーバレスでのセキュリティはより優しい）
- Security with serverless is harder （サーバレスでのセキュリティはより難しい）
- Four key areas apply to serverless security （4つのキーエリアがサーバレスセキュリティに適応される）
- Software supply chain security
- Delivery pipeline security
- Data flow security
- Attack detection
- lambhack! a very vulnerable lambda stack open source project （lambhackというLambda用の脆弱性のあるオープンソースプロジェクト）
- https://github.com/wickett/lambhack
なお、lambhack を一言で示すとこれです。面白いですね。
command := lambdaEvent.QueryParams["args"]
output := runner.Run(command)
サーバレスシステムのよい入門資料であると同時に、コマンドインジェクションできるサーバレスのアプリを使ってコンテナ内の状況を調べている面白い内容でした。
(滝澤)
マイクロサービス
Lyft's Envoy: Experiences operating a large service mesh
- スライドなし
LyftのMatt Klein氏によるLyftが開発しているEnvoyを紹介するセッションでした。 Envoyはマイクロサービス向けのロードバランサーとコミュニケーションバスという位置づけになります。
背景としては、私が大雑把に理解した話としては、Lyftのサービスのシステムに様々なものが必要になって、複雑になり、ばらばらに管理するのは大変なので、ロードバランサーとコミュニケーションバスのシステムを作ってしまえ、ということで出来たのがEnvoyということらしいです。
Architecture overview を見るとわかりますが、全部載せ感がすごいです。
セッションのスライド資料は公開されていませんが、Envoyの公式サイトに書いてある内容が充実しているので、Envoyについてはそちらで十分に把握できると思います。
また、Envoyを利用したマイクロサービス/サービスメッシュの管理プラットフォームであるIstio（「イスティオ」と呼んでいるっぽい）についても言及がありました。
ちなみに、翌日のキーノートのセッション「 Building cloud-native applications with Kubernetes and Istio」においてGoogleのKelsey Hightower氏がIstioについてデモをやっていました。
- 参考:
(滝澤)
ロードバランサー
Standing on the shoulders of giants: Unleashing the power of scriptable load balancers
- スライド: Standing on the Shoulders of Giants (PDF)
OpenResty(Nginx + LuaJIT)をロードバランサとして利用し、大量のトラフィックを複数の拠点にある複数のアプリケーションにすばやく自由自在にルーティングしているよという話でした。luaモジュールを使いロードバランサ内でアプリケーション毎に振り分け先を変えたり、DC間を跨いだ振り分けを行うことを"Routing for sharding"と呼んでいました。一時的にトラフィックをポージング(破棄しない)することでダウンタイムゼロでのfailoverなども出来るらしく、OpenRestyの万能感を感じたセッションでした。
(宮越)
データベース
Google Cloud Spanner: Global consistency at scale
- スライドなし
Miles Ward氏によるGoogle Cloud Spannerの紹介のセッションでした。Google Cloud SpannerはACIDトランザクションに準拠しながらも、NoSQLのような水平スケールが可能であり、また地理的にグローバルな冗長化がされているリレーショナルデータベースです。Google社内で必要となり開発されすでに5年以上利用されてきているそうです(今はベータ版として提供されています)。セッションでは動作デモやMySQLとのパフォーマンスの比較などについて説明がされていました。スライドは今のところ公開されていませんが、概要については公式ドキュメントに詳しく記載されています。Cloud Spanner のドキュメント。説明だけ聞くと夢のようなデータベースに見えますが、今後どうなっていくのかが気になります。
(宮越)
データサイエンス
A hands-on data science crash course for modeling and predicting the behavior of (large) distributed systems
- 資料: Data Science Tutorial (github)
CoScaleのBart De Vylder氏によるハンズオンセッションです。 モニタリングのデータに対して、以下のことをデータサイエンスを使って解析しようという内容でした。
- Anomaly Detection （異常検知）
- Data modeling （データモデリング（回帰分析））
- Machine learning （機械学習）
- Correlation and clustering （相関クラスタリング）
- Forecasting （予測分析）
異常検知は最近では監視のSaaSでも取り入れられている技術ですね。 周期性のあるデータに対して特異なデータを検知できますし、無駄にアラートを発生することを防ぐことができます。 相関クラスタリングは相関のあるホストやリソースを見つけ出すことにより、障害発生時の原因分析にも利用できると思います。
なお、ハンズオンの資料が公開されているので、ハンズオンを試すことができます。 ただし、github上の説明ページの実行コマンドのファイル名にtypoがあるので注意してください。
(滝澤)
障害テスト
Chaos engineering bootcamp
- スライド: Chaos engineering bootcamp (Speaker Deck)
カオスエンジニアリングとは何か・なぜ必要かという原理的な話と合わせて、実際に用意された分散システムを使って参加者全員でSimianArmyを使ったハンズオンを行いました。カオスエンジニアリングは特定の条件に対する障害テストとは異なり、認識出来ていない未知の弱点を継続的に見つけ出すことで耐障害性の強いシステムを作っていくという手法ということで、各企業で発生した過去の大障害のケーススタディと、カオスエンジニアリングで利用されるツールが紹介されており、カオスエンジニアリングを理解するには良い資料だと思いました。
別日に行われたThe road to chaosというセッションにも参加しましたが、こちらはカオスエンジニアリングを導入するにあたり文化的な障壁をどうするかという話と、NetFlixのChAP（Chaos Automation Platform）というプラットフォームの紹介がされていました。
(宮越)
Orchestrating chaos: Applying database research in the wild
- スライドなし
キーノートのセッションの一つで、カリフォルニア大学サンタクルーズ校（UC Santa Cruz）のPeter Alvaro氏による障害テストに関するセッションでした。
天才（Geniuses）がいれば障害が発生しそうな箇所を見つけて障害テストを行えるが、実際はそうではないので、Chaos EngineeringやJepsen TestingやLineage-driven Fault Injection (LDFI) といった障害テストの手法を使おうという話でした。
動画の一部が公開されています。
参考:
(滝澤)
障害調査
Troubleshooting data center networks: Fresh tools and perspectives
- スライド: Troubleshooting data center networks (PDF)
最新のデータセンターのネットワーク事情と、そのトラブルシューティング手法の話。最近のデータセンターでは完全マルチパス化・仮想化・高速化・ホワイトボックススイッチ化などが進んでいるようです。そのような進化の中でネットワークエンジニアが使う道具がpingやtracerouteなどでは対処できないという点から、最近使われているツール等が紹介されています。また、そもそもトラブルを起こさないよう適切なネットワーク構成にするための、構成管理方法についても言及されています。
(宮越)
Performance analysis superpowers with Linux eBPF
- スライド: Velocity 2017 Performance analysis superpowers with Linux eBPF (SlideShare)
計測ツールの紹介でおなじみのNetflixのBrendan Gregg氏のセッションでした。 今回はeBPF (Enhanced BPF)を使った計測ツールの紹介です。
Linux 4.4以降でサポートされたカーネルのトレーシング機能であるeBPFを使った次のようなツールを紹介していました。
- execsnoop: exec()の実行をトレース
- ext4slower: 下記コマンドのファイルシステムに対するレイテンシーを計測
- biolatency: レイテンシー毎の集計
- tcplife: 各デーモン毎のTCPセッションの継続時間などを表示
- gethostlatency: 名前解決のレイテンシーを表示
- runqlat: キューのレイテンシーの集計
現時点では利用できる環境は限られていますが、障害の原因調査などに利用できそうな技術なので、将来は楽しみです。
(滝澤)
チーム運営
10,000 messages a minute: Lessons learned from building engineering teams under pressure
- スライドなし
Slack社内でのインフラエンジニアのチームビルディングについて。心理的安全性は重要だがそれだけではチームは成長しない。人の多様性がパフォーマンスを高くすると言われているがその場合は問題が起こりやすい。チームの成長には 心理的安全性 + clarity(明瞭さ)が必要であり、それを育てるにはどのような対策を行えばよいかTIPSが紹介されていました。ハートビーツ社内でも近しいチームビルディングのフレームワークが利用されているのですが、共通点があったり参考にできそうなところもあったりで面白く感じました。
(宮越)
Incident Command: The far side of the edge
- スライドなし
FastlyのSite Reliability EngineeringのVPのLisa Phillips氏とSecurity EngineeringのVPであるMaarten Van Horenbeeck氏による、 Fastlyにおいてインシデント・レスポンス・フレームワークとしてのIncident Commandをどのように構築して実行してきたかを紹介するセッションでした。
このベースとなっている"Incident Command System"は火災も含めた緊急事態に対応するフレームワークであり、 FEMA（Federal Emergency Management Agency, アメリカ合衆国連邦緊急事態管理庁）によりNational Incident Management System(NIMS)として公開されています。 これをIT方面にも適応しようという動きがあり、昨年のVelocityでもチュートリアルセッションがありました。Fastlyでの事例もIncident Comannd SystemをITの運用に載せた形となります。
目的として次のものをあげていました。
- Decision Making （意思決定）
- Reduce MTTR （平均復旧時間の減少）
- Provide Comms （コミュニケーション手段の提供）
- Understand Impact （影響の理解）
- Structured Involvement （構造化された関与）
- Improve for Next Time （次回のための改善）
Incident Commandの内容としては次のようなことを述べていました。細かい話もありますが、後述の資料をご覧ください。
- Fastlyでは、インシデントと分類される様々なイベントが発生している。
- Fastlyでは、NOCを持っていなく、チーム毎にそれぞれ監視システムを持っていている。
- チーム毎のpager rotations（緊急時の担当の持ち回りのこと？）を持っていて、会社全体としてはpager rotationとしてIncident Commander（現場指揮官）を指名している。
- Incident Commander（現場指揮官）はFastlyのシステムに深い理解があり、各チームの役割やリーダーに精通していて、組織的な信頼がある。
- 大規模なインシデントが発生すると、ボランティアとして個別に対応する人が出てくるので、コミュニケーションチャネルを決める。
- インシデントを記録し、必要なインシデントレポートを作成して、継続的な改善につなげている。
本セッションの資料は公開されていませんが、別のイベントの類似の資料があるのでご覧ください。
- 資料:
- Incident Command: The far side of the edge (SlideShare) ※別のイベントでの類似の資料
(滝澤)
最後に
最後に全体的な所感を述べてみます。
宮越より
初めて海外のカンファレンスに参加したのですが、規模が大きくスピーカーが皆かっこよく思えとても楽しいイベントでした。わたしが参加した範囲ではカオスエンジニアリング、マイクロサービス、分散システム、kubernetes、オーケストレーション、CI/CD、モニタリングが主な議題となっていました。すでにコンテナ化や分散システムが当たり前となっており、その上でどうするかというステージになっていて、日本の数歩先を進んでいるように感じました。カオスエンジニアリングはバズワード的なものになってしまうかわかりませんが、個人的にはもう少し深掘りしてければと思っています。
滝澤より
次の技術のセッションが多かった印象です。
- コンテナ・オーケストレーション。特にkubernetes。
- マイクロサービス
- CI/CD パイプライン
- 障害テスト
- チームマネジメント
チームマネジメントのセッションは毎年あるような気がするので永遠の課題なのかもしれません。
個人的にはマイクロサービス向けロードバランサーのEnvoy/Istioが面白そうでした。
昨年までセッションがあったRUM (Real User Monitoring)やAPM (Application Performance Monitoring)そのものについてのセッションは今年はありませんでした。普通に使われる技術になったためだと思われます。
