Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。_原文(投稿日:2019/02/14)へのリンク分散システムの複雑性はコードの中ではなく、サービスや機能の間にある。Conferenceで、このように説明した。テスタはしばしば、システム動作の最大の理解者である。システムのどこが悪いのかについて優れた仮説を持ち、それを極めて短期間に検証することができるのは彼らなのだ。基調講演の中で氏は、複雑な分散システムになることで何が変わるのかを説明した。システムがモノリスである場合、ある処理をどのコードが行っているのかを特定するのは難しいかも知れないが、システムを通過する要求の流れを決めるのは簡単であり、通信は主にプロセス内で行われる。分散システムでは、複雑性はシステム内からシステム間に移っているのだ、とWells氏は主張する。マイクロサービスのコードは単純だが、ルーティングは複雑であり、http上あるいはキュー経由で行われる。事態をさらに難しくするのは、Wells氏いわく、ある要求が一時的なエラーで失敗しても、数秒後に繰り返すと成功することが少なくない、ということだ。バックオフとリトライを実装することは合理的ではあるが、それによって、要求に対する応答の間に何が起こったかを正確に把握することが難しくなっている、と氏は指摘する。Wells氏はリスクベースのアプローチを採用して,実際に重要な問題にテスト作業を集中する方法を提案する。問題が発生したことを素早く見つけて,それを素早く修正する必要がある,そのためには問題を解決するための可観測性を備えたシステムを開発しなければならない,と氏は言う。複雑な分散システムをテストするためには,問題の早期発見と,可能な限り早い価値提供という,2つのバランスを取る必要がある,とWells氏は指摘する。いくつかの問題は,運用に至るまで見つからないものと受け止めた方がよいだろう,その上で,できる限り早い発見と修正のために最適化するべきだ,というのが氏の意見だ。Wells氏に,複雑な分散システムのテストについて話を聞いた。テストを始めて分かったことは,システムの完全なレプリカをローカルに立ち上げようとしてもうまくいかない,ということです。これは開発者にとっても,テスタにとっても同じです。運用システムのレプリカの作成にいくら時間を費やしても,結局はどうにもならないのです。これにはシステムの複雑さが関係しています。特定の変更に対して想定される影響範囲を評価できなければ,回帰テストに多くの時間が必要になります。これがボトルネックになると同時に,問題の発見を不可能にしていることが分かりました。多くのことがそうであるように,問題はコミュニケーションにあります。開発者が自分の行ったことを理解できるように説明してくれれば,テスト担当者は変更された中から,最もリスクの高い可能性のある部分をピンポイントで突き止めることができます。有効なのは,継続的デリバリとマイクロサービスです。マイクロサービスには極めて明確な境界があるので,変更は小さく,自己完結的なものになります。,(書籍"Accelerate"などの)調査結果から,小規模な変更を頻繁にリリース可能な企業では,変更に対する障害発生率が極めて低いことが分かっています。これはおそらく,システム内よりもチーム間のバウンダリで行うべきものでしょう。分散システムでは,問題の多くはリリースされたコード自体とはほとんど関係がありません。コードが実行される環境,あるいはサービス間の依存関係に関わっていることが多いのです。ひとつの変更が,予期しない別の部分でエラーを発生させるのです。そのサービスは,同じチームが所有するものではないかも知れません。自分たちのAPIを呼び出していることさえ知らない場合もあるのです。変更を運用環境に移行した後には,問題の早期発見とロールバックが重要になります。monitoring)のようなものや,実際のイベントが完全に成功したことをチェックするビジネス機能レベルの監視が必要になります。私たちの仕事はコンテンツの公開ですので,各リージョンの関連するすべてのデータストアが正しく更新されていることをチェックして,問題があれば警告するようにしています。私たちはこれを,もっと下位の環境でも行っています。不安定な受け入れテストの代用として,このテストを実施しているのです。それまでは,変更時のセットアップ変更が大変でしたが,これらのアーキテクチャで状況は大きく変わります。問題点を解決可能にするためには、可観測性を備えたシステムを開発する必要があります。それは例えば、すべてのログをひとつのログストアに集約した上で、クエリを簡単に実行できるように構造化しておく必要がある、というようなことです。最終的にはログをサンプリングすることになる(要求が複数のサービスを通過するので、モノリスで経験したよりも数桁多いログが収集される可能性があります)かも知れませんが、その場合でも、特定のログがすべて、確実に格納されていることが必要なはずですし、ユニークなトランザクションIDを使ってそれらを関連付けられた方がよいと思うでしょう。メトリクスも取り込みたいと思うかも知れませんが、これは過剰になりがちです。本当に必要なのは、ユーザコール数や要求率、エラー率(おそらくは要求率の割合として)、要求期間(REDメトリクスとも呼ばれます)といった、サービスのトップレベルでのメトリックスのはずなのです。私の経験から、テスタはプロダクトオーナと並んで、システムの挙動を最もよく理解できていることが少なくありません。(さらには、テスタが最終的にプロダクトオーナになることも多いのです)。これには2つの意味があります。ひとつは、問題に対してテスタの立てる仮説が優れていることです。これはテスタが、APIコールやWebサイトのフローをすでに知っているからです。問題が発生する前にも、彼らは多くの価値を提供することができます。それ以外に考えられますか?あるいは、このキーが期限切れになったら?複雑な分散システムでは、このような仮説と回復力のテストは非常に重要で、価値の高いものなのです。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。