実践的でいいドキュメント。
Stitch Fixではデータサイエンスとエンジニアリングの比率が1対1であることです。私が仕事をしているチームには、ソフトウェアエンジニアが100人以上、データサイエンスに取り組むデータサイエンティストとアルゴリズム開発者がおよそ80人います。私の知る限り、この比率は業界で独特です。これほど1対1に近い比率の会社は他に知りません。パフォーマンスの高い組織と低い組織の違いを調べています。組織のパフォーマンスが高ければ高いほど、すばやく動き、安定しています。スピードと安定性のどちらかを選ぶ必要はありません。両方を兼ね備えることができるのです。
よりパフォーマンスの高い組織は、1ヶ月に1度ではなく、1日に何度もデプロイします。ソースのコミットからデプロイまでの待ち時間は、1時間未満です。他の組織だと1週間かかるかもしれません。これがスピードです。
安定性に関して、ハイパフォーマンスな組織は障害から1時間で復旧します。パフォーマンスの低い組織では、おそらく1日かかるでしょう。障害の発生率も低くなっています。ハイパフォーマンスな組織では、デプロイしてうまくいかずにロールバックを必要とする頻度はゼロに近くなりますが、遅い組織だと、頻繁にする必要があるでしょう。
スピードと安定性だけではありません。技術的な指標だけではありません。収益、市場シェア、生産性といったビジネス目標を上回る可能性も、ハイパフォーマンスな組織の方が2.5倍高いのです。そのため、これはエンジニアだけでなく、ビジネスの人たちにとっても重要なことです。
共有データベースの分割プロセス
このやり方は、自分でも2000年から使ってきましたよ。
非同期イベントとローカルキャッシュとの組み合わせに関係しています。引き続き、顧客サービスは顧客の表現を所有しますが、顧客データ（例えば顧客の住所）に変更があったとき、顧客サービスはアップデートイベントを送ります。フルフィルメントサービスはそのイベントをリッスンし、住所変更があると、その住所をローカルにキャッシュします。それから、フルフィルメントセンターは素早くボックスを発送します。
データベース用語で「ビューのマテリアライズ」と呼ばれることを行うサービスを作成することです。 消費フィードバックサービスはこれらのイベントをリッスンし、その結合をマテリアライズします。言い換えると、すべての商品に関して得られるフィードバックを、すべて1つのキャッシュに覚えます。もっと洒落た言い方をすると、商品と注文の非正規化結合を独自のローカルストレージに保持するということです。
Cでやったことをやり直し、1つ以上のイベントを生成し、それから、Bサービスでやったことをやり直し、1つ以上のイベントを生成し、それから、Aでやったことをやり直します。これがSagaのコアとなる概念です。その背後には、非常に多くの詳細があります。Sagaについてもっと知りたければ、Chris Richardson氏のQConプレゼンテーション、「 Data Consistency in Microservices Using Sagas」を強くお勧めします。
Comments