今日のために作る。明日に備える。失敗に備える。
ほかに 28 言語で読めます
English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
モジュール5／7：Data Architectコース第1章「データアーキテクトのように考える」。各モジュールは単独でも読めます。 前へ：アーキテクチャはトレードオフの技術である · 次へ：ツールを知る：9つの問い
このモジュールが答える問い： 成長と失敗に備えながら、今日の要件に向けて設計するにはどうすればよいか？
アーキテクチャで最も陥りやすい誤りの一つは、目の前にある要件だけに向けて設計することです。プロジェクトがあり、バックログがあり、要件があります。それを満たすものを作ります。うまく動き、勝利を宣言します。半年後、ビジネスが変わる、データが増える、別の事業部門が使いたがる、企業を買収する、新しいシステムを連携する必要が出る、あるいは誰も想定していなかった何かが失敗します。
どれもアーキテクトを驚かせるべきことではありません。これから起きることをすべて予測することはできませんが、何かは起きるとわかった上で設計することはできます。だから私は、3つのレンズでアーキテクチャを見ます。
今日のために作る。 明日に備える。 失敗に備える。
3つすべてが必要です。
今日のために作る
Section titled “今日のために作る ”アーキテクチャは、私たちが実際に抱えている問題から始まります。当たり前に聞こえますが、アーキテクトは短期的な思考とは逆の誤りを犯すことがあります。アーキテクチャを作り込みすぎるのです。12社を買収し、顧客が10億人になり、40か国に展開し、すべてのシステムにリアルタイム連携が必要になったら？ そうなるかもしれません。でも、それは現実的な可能性でしょうか、それとも問題をでっち上げているのでしょうか？ アーキテクチャとは、想像できる限り最も洗練されたシステムを作ることではありません。適切なシステムを作ることです。
ですから、今日から始めましょう。ビジネスが必要としていること、実際のボリューム、ユーザー数、トランザクション数、データがどれくらいの頻度で変わり、どれくらい速く移動しなければならないか、誰がアクセスする必要があるか、データがどこから来てどこへ行くのか。そして何より大切なのは、なぜ？ それらの答えが、設計するための具体的な材料を与えてくれます。
暗黙の要件を探す
Section titled “暗黙の要件を探す ”与えられた要件が、必ずしもすべての要件ではありません。ほとんどの場合、暗黙の要件があります。
ビジネスが「顧客データをSalesforceに入れる必要があります」と言います。わかりました。では、誰かがそのデータを所有し、どれくらい新しくなければならないかを決める必要があります。ソースシステムが停止したらどうなるか、同期が失敗したらどう気づくか、Salesforceとソースが食い違ったらどちらが勝つかを知る必要があります。保持期間、アクセスモデル、機密項目についての判断、そして誤ったデータを修正する方法が必要です。
どれもユーザーストーリーには書かれていませんでした。それでも、すべてアーキテクチャです。アーキテクトになることの大きな部分は、まだ誰も尋ねていない問いを見抜けるようになることです。
数字を知る
Section titled “数字を知る ”私はいつもアーキテクトに数値化を求めます。データがたくさんある、と言わないでください。どれくらいなのかを教えてください。1万、1,000万、1億、10億？ それぞれまったく違うアーキテクチャです。連携は頻繁に動く、と言わないでください。1時間ごと、1分ごと、1秒に1,000回？ 急成長している、と言わないでください。どれくらいの速さですか？
もっとよい数字がないとき、私の基準は年30パーセントの成長です。予測ではありません。考えざるを得なくするための仕掛けです。今日1,000万件のレコードがあると言われたら、議論を1,000万で止めたくありません。年30パーセントなら、来年はおよそ1,300万、その翌年は1,700万、さらにその翌年は約2,200万になります。さあ、設計の話をしましょう。30パーセントなんてありえない、とビジネス側が言うなら、それは結構です。本当の数字を教えてください。大事なのは、成長をアーキテクチャの議論の一部にすることです。
私はこれをスティーブのゼロの数（Steve’s Number of Zeros）と呼んでいます。ゼロが一つ増えるだけで、アーキテクチャがまるごと変わることがあります。1万、10万、100万、1,000万、1億。機能は変わらず、要件も変わっていないかもしれません。それでもアーキテクチャは変わるかもしれないのです。
モジュール1の予約の話を覚えていますか？ 実際の数字を当てはめてみましょう。1,200以上の拠点、1拠点1日100件の予約、週6日営業、年間約305日。初年度で3,600万件を超える予約です。1回の来店で2つのレコードができるので、7,300万レコードを超えます。さらに5年分の履歴を保持し、年30パーセントで成長すると、6億5,000万レコードを超えます。同じ機能、同じ要件。ゼロがあと2つ増えるだけで、まったく違うアーキテクチャになります。
明日に備える
Section titled “明日に備える ”今日を理解したら、先を見ます。何が変わる可能性が十分にあるか？ ボリュームもその一部ですが、明日はただ増えるだけではありません。違うものになることもあります。製品、事業部門、国が増える。プライバシーの要件が変わる。新しいチャネルや連携ができる。合併や買収が起きる。新しいマスターデータ戦略や分析プラットフォームが入る。人間向けにだけ設計された情報をAIエージェントが使うようになる。
だから私は、アーキテクチャが絶え間ない変更ではなく追加によって成長できるかどうかを、とても気にかけています。ビジネスが製品を追加したら、モデルは受け止められるか？ 別のシステムがデータを必要としたら、きれいに公開できるか？ ボリュームが跳ね上がったら、進む先があるか？ ビジネスの構造が変わったら、データモデルを壊さなければならないか？ 未来を完璧に予測しようとしているのではありません。自分で自分を追い詰めないようにしているのです。
明日のものを今日作らない
Section titled “明日のものを今日作らない ”ここにはバランスがあります。明日に備えるとは、明日のシステムを今日作ることではありません。今10万件のレコードがあり、5年後に1億件になるかもしれないとしても、1億件向けのアーキテクチャを今作るという意味ではありません。まだ必要のないコストと複雑さを持ち込むことになるかもしれません。
答えてほしい問いはこれです。今日のアーキテクチャは、明日のアーキテクチャへと進化できるか？ 明確な道筋を持ってシンプルに始められるなら、何年も前倒しで複雑さのコストを払うより、たいていそのほうがよいのです。危険なのは小さく始めることではありません。行き場のない場所から始めることです。
失敗に備える
Section titled “失敗に備える ”では、誰も話したがらない部分です。物事は失敗します。すべての部品がずっと利用可能であり続け、すべての連携が成功し、すべてのユーザーが完璧なデータを入力し、すべての外部システムがドキュメント通りに振る舞うシステムを、私は一度も設計したことがありません。ですから、そんなシステムを設計しないでください。
何が失敗し得るかを問い、次に失敗したら何が起きるかを問いましょう。連携がタイムアウトする。APIがリクエストを拒否する。夜間のロードが80万件を処理し、そのうち20万件で失敗する。ソースシステムが停止する。ユーザーが無効なデータを入力する。外部IDが2回現れる。上流のシステムが項目名を変えずに値の形式を変える。あるプロセスが一方のシステムでは成功し、もう一方では失敗する。これらは珍しい例外ケースではありません。本番環境とはこういうものです。
部分的な成功も、理解すべき失敗である
Section titled “部分的な成功も、理解すべき失敗である ”データアーキテクチャでは、部分的な失敗が特に危険です。100万件のレコードを移動し、プロセスが完了と報告したとします。すばらしい。でも、本当に100万件届いたのでしょうか、それとも999,997件で、欠けている3件はどれでしょう？ 20万件が失敗したのかもしれませんし、一部が2回作成されたのかもしれませんし、全部届いたものの一部の項目で変換に失敗したのかもしれません。
「ジョブ完了」は、データが正しいことと同じではありません。データアーキテクトは照合（リコンシリエーション）を考えます。何が起きるはずだったのか、実際に何が起きたのか、その差は何か、どうやって知るのか？ そして、それにどう対処するのか？
システムが複雑になったとき、私はこうしています。レコードは左から右へ、AからBへ送られます。次にBが何かを送り返します。受け取って保存したレコードごとの確認です。これでAは、送ったものと確認されたものを比べられます。すべてのレコードに確認があれば、その実行は成功です。確認が一つでも欠けていれば、ジョブのステータスが何と言おうと成功ではありません。そして、どのレコードを追えばよいかが正確にわかります。再試行する、人に回す、アラートを上げる。
うまく失敗する
Section titled “うまく失敗する ”失敗が起きたとき、私はシステムが次に何をするのかを知りたいのです。再試行するのか、それは自動なのか。同じトランザクションが2回処理されたらどうなるか。失敗したレコードはどこへ行き、正常なレコードは不良レコードを追い越して流れ続けるのか。誰に、どんな情報とともにアラートが届き、その人はどうやって失敗を再実行するのか。そして、何かがうまくいかなかったことにユーザーはどう気づくのか。
そして最も大切なのは、問題を悪化させずに復旧できるか？ 重複データを生む再試行戦略は、復旧戦略とはとても言えません。よいアーキテクチャは失敗を前提にし、戻る道を用意しています。
大切なものを監視する
Section titled “大切なものを監視する ”監視のない失敗への備えは、本当の備えではありません。連携が午前2時に失敗し、3日後に顧客から電話が来るまで誰も気づかなかったなら、私たちには運用のアーキテクチャがなかったのです。あったのは希望だけです。
何を観測できるようにする必要があるかを決めましょう。プロセスは動いたか、どれくらい時間がかかったか、何件処理し、何件成功し、何件失敗したか？ ボリュームが急にいつもと違っていないか？ バックログは増えていないか、エラーは増えていないか？ アーキテクチャはデプロイが成功したところで終わりません。明日このシステムを誰かが運用しなければならず、それも設計の一部です。
3つの方向すべてで考える
Section titled “3つの方向すべてで考える ”このコースの残りでも、3つのレンズを当て続けてください。データモデルを設計するなら：今日うまくいくか、明日成長できるか、データが間違っていたり不完全だったりしたら何が起きるか？ 連携なら：今日のデータを動かせるか、明日のボリュームとシステムに対応できるか、片側が停止していたら何が起きるか？ 大規模データボリュームなら：今日何があり、数字はどこへ向かっていて、大きな処理が部分的にしか成功しなかったらどう復旧するか？
テクノロジーは章ごとに変わります。問いは変わりません。
アーキテクチャは時間の中に存在する
Section titled “アーキテクチャは時間の中に存在する ”開発者は、要件を見て「これは動くか？」と問えば済むこともあります。アーキテクトはもっと問わなければなりません。今日動くか、明日も動き続けるか、そしてまったく動かないときに何が起きるか？ この3つの問いが、実装の先へ、システムの生涯へと私たちを連れて行きます。
将来のすべての要件を予測することも、すべての失敗を防ぐこともできません。それは目的ではありません。目的は、今日わかっていることに対して適切なものを作り、明日進む先を残しておき、現実が思い通りにならないときの計画を持っておくことです。
今日のために作る。明日に備える。失敗に備える。 この3つのレンズを何度も使っていきます。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- 本当のボリュームと成長はどれくらいか、そしてどの数字が設計を変えるか。
- ビジネスがまだ口にしていない暗黙の要件はどれか。
- 明日のシステムを今日作ることなく、今日の設計をどう明日の設計へ進化させられるか。
- 何かが失敗したら何が起きるか：復旧、照合、監視。