[レポート]急がば回れ: ユニットテスト或いは連携テストが壊れている場合 #reinvent #DEM11

reinvent 2019 - DEM11-S Do more with less: Unit and integration testing is broken のレポートです。

AWS re:Invent 2019

#AWS

#イベントレポート

haoyayoi

2019.12.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

DEM11-S Do more with less: Unit and integration testing is broken のレポートです。

翻訳を主に、幾つか触れられているサービスの補足をします。

セッションスピーカー Kevin Crawley氏について

約20年ほどソフトウェアデベロッパーを続けています。Gung-Hoにいる間、テストはソフトウェア開発をこれ以上なく輝かしいものにするものだと考えてきました。正直なところ、それは実感としてあります。どうすればより良い開発者になれるのか、よりよいシステムの疎結合ができるのか、深く掘り下げられるのか。

システムのデザインをしていた時がありましたが、途中いくつかのトレードオフとなるものがありました。それらトレードオフはしばしば見落とされていたと思います。

Stannahという企業で働いており、当社はアプリケーション性能管理が主で、真摯にモニタリングと向き合っていました。当時の担当は開発関連で、詳しくはカンファレンスのオンラインセミナーでお話したことをブログに投稿しています。

Kevin's Blog

また、プロダクトはSREトピックに焦点を当てており、特定の領域にてプロダクトマネージャや開発者へツール構築の支援をしています。テネシー州ナッシュビル市郊外のスタートアップでの主要なSREも務めておられます。

特に、カスタマーへソフトウェアを提供する改善施策として行っている、Single Musicの分散トレーシングによる高度な監視への活用についてどうやっているのか少し触れます。

テストの文化

広く知られているようなアジャイルフレームワークはどのくらいテストされているのでしょう。アジャイルフレームワークを経験されているのであれば、テストについて何もいうことはありません。

主に求められるのは品質のある製品版ソフトウェアを提供することです。カスタマーへ実際に公開する前に、素晴らしいソフトウェアの作り方の確認と、問題を解決可能にするため本番にて監視できる方法を議論するでしょう。

今日使われているツールは、カナリアテスト・A/Bテスト・Blue/Greenデプロイなどが実際に利用可能となっています。いくつかの例の一つとして、承認不要でテスト完了が信頼されているもの等は実際によいアイデアでしょう。理由としてはシステムを素早く動かすためです。とても急速にソフトウェアが作られており、大抵は実際に変更がある筈の範囲へのテストを定義し、リファクタリングによって完了とします。

これはテストを中心にして育った、文化のようなものです。単純な承認はしません。多くの人達がテスト駆動開発の効果について学んでいるからです。学んだことについてはスライドをTwitter上で公開しており、読み解くことができます。本質的に言いたいのは、確実にテストを行うと欠陥がへりますが、努力と継続とソフトウェア生産性とトレードオフであるということです。

もし、前もってテストを沢山こなすのであれば開発は遅くなり、当然、銀行や原子力発電所或いは重要な任務等でなければ、今日のビジネス環境では求められなくなるでしょう。ばかげた例ですが、ソフトウェアが誰かの命を奪うような結果になるのであれば、確実にテストを書くことができるでしょう。

ユニットテストはタール池にコードを突っ込むような所業である

環境はさらなるサービス、エンドポイント、システムの導入にて複雑さが増していくと、早期テストによる恩恵はなくなる傾向にあります。これに対する答えは何かというと、更なる連携テストでしょうか。

Everybody has a testing environment, Some people are lucky enough enough to have a totally separate environment to run production in. 本番が走っている環境と隔てられたテスト環境を持っているなんて羨ましいな

私はTwitterで見かけた上図の引用が大好きです。誰が言ったのかは知りませんが、すでにテスト環境と本番が隔てられている身としては馬鹿げたものです。

何をテストすべきか

私達はとにかく生きているうちにテストを行うべきです。何かのためにテストが必要です。テストをしたいんです。

オープンソースの上で、重要なソフトウェアは沢山の回数実行されます。率直により良いソフトウェアを公開したいのは明確でしょう。ソフトウェアに一貫して問題があれば公開を保留し、テストを通すコードを特定します。クリティカルではないユーザアクションへのテストを、ユーザに不必要に割り込んでまで行うべきではありません。

誰かのアボカドトーストが好きになるくらいのモニタリング、支柱エラー、CRUD(Create、Read、Update、Delete) ※edge concernsについてはGoogle Scholarですらそのものが該当しなかったため、造語の可能性があります。

分散トレーシングについて

分散トレーシングについて、及びモニタリングシステムで依存を取り除く支援をどのようにやっているのかについて。

分散トレーシングはGoogleから2010年に発表されました。とても大きな組織は数百のチームと数千のサービス、数十のプログラミング言語があり、モニタ方法も一般的ではありません。やりとりは個々で発生します。そこで彼らはDapperと呼ばれるものを作りました。

Dapper, a Large-Scale Distributed Systems Tracing Infrastructure – Google Research

サービス、データベース、メッセージ間で発生する各リクエストにヘッダーを付与します。ヘッダーはエージェントあるいはモニタリングシステムの結びつきを支援し、一つのリクエストが到着するまでにどのくらい掛かっているか等の追跡が可能になります。骨の折れる実装になりそうですが、実際にはやりとりの出力や制御を行う各メソッドに関数をアドオンするのみです。

メッセージキューシステムだろうとデータベーストランザクションシステムであろうと、幸いなことにJDBCのようになります。数多くの動作するライブラリが存在し、Stano Ochotnickyが動作するようにしてくれるでしょう。

分散トレーシングから何を得るのか

性能分析に加えて、テスト、デバッグの機械学習での集約で申し分のない沢山のデータが集まっています。いえ、むしろやることがない時に没頭できる巨大な湖を手に入れました。

何をするのかというと、選択された集約済みイベントのリクエストと呼ばれるものを全てまとめて文脈化します。モニタリングシステムにてこれら異なるデータポイントをまとめることで、唐突に、システムの欠陥の原因がいつどこで生じたのか正確に理解できるようになります。

選択された集約済みイベントのリクエストとは何かというと、サービスアプリケーションとエンドポイントにて集約化されたデータで個別バケットを作っていることを意味します。スループット遅延エラーレートとこれらバケット全ての飽和でのゴールデンメトリックスをロールアップします。トレーシングにはこれらのメトリックスを含みます。特定のトレーシング時あるいは一定間隔で失敗する時、インフラ構成、コンテナ、Kubernetes Pod、ホスト、クラウドプロバイダに結びつける事ができます。これら全てが結びつけられることで、問題のある箇所をとても見つけやすくなります。

SingleMusicのケーススタディ

2018年にガレージで始めて、約6ヶ月は8〜15台のDell上で動いていました。OrchestratorからDockerで起動させ、コンテナベースのマイクロサービスでした。

github/orchestrator: MySQL replication topology management and HA

AWSへの移行物語

ある時、海外のどこかのカンファレンスで話して疲れ果てた上で朝2時に電話で起こされ、CTOから「直して」と言われました。「やってやるさ」と。そして、修正を行うためにも海を横切ることにしました。彼は「分からない」とこぼします。そこで「私の配偶者を呼んで彼女にサーバの電源をいれさせてくれ」と。朝の2時に文字通り妻と電話でガレージのサーバの性能向上を、彼女を通して試みました。彼女は二度とやりたくないようです。