ソフトウェアアーキテクトの方法でイベントストリーミングのニーズを評価する

<font color="Grey">*[Evaluating your event streaming needs, the software architect way](https://aiven.io/blog/evaluating-your-event-streaming-needs-the-software-architect-way)の翻訳です。*</font>

2022年12月16日

# イベント・ストリーミングのニーズを評価する、ソフトウェア・アーキテクトの方法

ソフトウェア・アーキテクト流のストリーミング・ソリューションについて、オーバーエンジニアのデイビッド・エスポジートと一緒に考えてみましょう。

## ソフトウェアアーキテクトとは？


イベント・ストリーミング・プラットフォームとは何か」と10人に尋ねれば、10通りの答えが返ってくるだろう（「知らない」「どうやってここに入ったんだ」は除く）。しかし、このブログ記事の目的では、イベント・ストリーミング・プラットフォームとは、*イベントドリブン・アプリが短い間隔でデータ更新を提供するために、その上で実行されたり、統合されたりするインフラやテクノロジーのこと*である。


この定義は、インフラストラクチャの観点から、どのような技術を採用できるか、つまり、裸のDIYから、公開されたイベントからまるで魔法のように洞察が現れる抽象的なアーキテクチャまで、様々な選択肢をカバーする。


私たちは、あなたのためにその決定を下すためにここにいるのではありません。私たちは、あなた自身が決断を下し、それに伴うリスクや要因を理解する手助けをするためにここにいるのです。すべての答えが必要なわけではありませんが、どのような質問をすべきかを知る必要があります。それがソフトウェア・アーキテクトの仕事です。


ソフトウェアアーキテクトは、次のような能力を備えています：


* アプリ、業界、インフラレベルの技術的な専門知識
* 問題解決における失敗や成功の経験
* 異なるシステムがどのように相互作用するかについての型にはまらない好奇心。


この記事では、「ソフトウェア・アーキテクトの道」を学び、それがどのようにあなたのイベント・ストリーミング・ソリューションに役立つかについて説明する：


* [アーキテクトの知恵](#the-wisdom-of-architect)
* [ダウンタイムについて考える](#the-inevitability-of-downtime)
* [チームへの影響について考える](#questions-of-team-impact)
* 統合、ツール、[オープンソースについて考える](#building-on-the-shoulders-of-giants-integrations-tooling-and-open-source)
* [総所有コストについて考える](#total-cost-of-ownership)


## 建築家の知恵


"知恵 "とは、失敗の経験を表す素敵な言葉に過ぎない。あるいは成功！しかし、たいていは失敗だ。


ソフトウェア・アーキテクトは、システムがどのように相互作用するのか、ツールやシステムがどのようにお互いを壊してしまうのか、そして、そうなったときに（そうなった場合ではなく！）何が影響を受けるのかに好奇心を抱く。



**技術的なレベルでは：***

*ソフトウェア・アーキテクトは、パフォーマンス、回復力、信頼性に関して、自分のコードが他のコードにどのような影響を与えるかを見ている。


** 部門レベルでは:**

*ソフトウェアアーキテクトは、自分のコードが他のチームにどのような影響を与えるかを、互換性、契約、権限付与に関して見ている。


**会社レベルでは：***。

*ソフトウェアアーキテクトは、自分のコードが他部門や他企業にどのような影響を与えるか、特に市場投入への影響に関連するものを見る。



ソフトウェア・アーキテクトは、答えを持っている以上に多くの質問をする。そして、それがあるべき姿なのだ。


* 一晩で顧客を2倍にしたら、何が最初に壊れるのか？
* 一晩で顧客数を10倍にしたら、何が一番最初に壊れるのか？
* どのようなエンドユーザー体験をお望みですか？
* エラーが起きたとき、私たちは何をすればいいのか？
* ダウンタイム1分で、あなたの会社にどれだけのコストがかかりますか？


ソフトウェア・アーキテクトが直面するいくつかの課題に対処するためには、アーキテクトのような考え方を学ぶ必要がある。そしてご想像の通り、たくさんの質問をすることになる。


#### 変革の到来

さまざまな業界の成功企業が、変革戦略の一環としてマネージド・データ・プラットフォームをどのように活用しているのでしょうか。彼らがどのようにビジネスや技術的な課題を解決したのか、電子書籍でご覧ください。

[こちらから](https://aiven.io/ebook/how-a-cloud-data-platform-can-drive-transformation-in-your-business?utm_source=ebook&utm_medium=internal&utm_campaign=transformation_ebook&utm_content=evaluating-your-event-streaming-needs-the-software-architect-way)
## ダウンタイムの必然性


クラウドは未来であり、それが何であるかを多くの人が（実際には知らないまま）「知っている」という事実のために、ある種の技術的な神秘性を持っている。しかし、それはまだ箱であり、どこかの壁に接続されている。そして故障は、「もし」ではなく「いつ」の問題なのだ。


ダウンタイムは*起こる*。準備はできていますか？


### ダウンタイムがないなんて信じられない。


賢明なソフトウェアアーキテクト（またはソフトウェアアーキテクトの思想家）は、特にダウンタイムに関しては、サービスレベル契約（SLA）の細かい活字をすべて読む。


例えば、多くの場合、メンテナンスウィンドウはダウンタイムとしてカウントされないことをご存知ですか？そして、それが*重大な*違いを生むこともあるのです。


細かい字を読み、適用除外に注意しましょう！


### オール・ザ・ナインズ


アップタイムナインと、**obligated**アップタイムと**observed**アップタイムの違いに特に注意してください。


企業が99.9％のアップタイム、99.99％のアップタイム、99.999％のアップタイムを提供している場合、それは大きな違いに見えません。しかし、これらは年間数秒、数分、数時間のダウンタイムの違いを意味します。


例えば3ナインであれば、年間約9時間のダウンタイムが発生することになります。5ナインなら年間5分*になる。つまり、1ヶ月に約30秒のダウンタイムに実質的に*契約上同意*していることになる。しかし、1年に1回か2回の大きな停止があれば、それで十分だ。これは、医療、規制産業、一部の金融機関などで見られるアップタイムSLAのレベルである。


さて、これは**オブザーブド・アップタイム**と同じでしょうか？いいえ、違います。まず、ほんの一例ですが、[メンテナンス免除](#i-cant-believe-its-not-downtime)があります。また、SLAを満たさない場合、クレジットを配ることで稼働時間の不足をカバーする企業もある。そしてそれは素晴らしいことではない。


### 災害が起きたとき


災害復旧計画を持つことは重要です。災害復旧計画をお持ちですか？それは素晴らしいことだ！しかし、もしあなたが災害のシナリオを実践し、その計画を*使って*いないのであれば、あなたは実際には災害復旧計画を持っていないことになります。あなたが持っているのは、停電の間におそらく起こると*考えている*ことに対処するための計画です。


システムに障害が発生したらどうなるのか？あなたのインフラはデータ損失のリスクにさらされていますか？データ損失は大丈夫ですか？様々な潜在的な障害ケースとそれに対する対策を理解することは非常に重要です。


## チームへの影響に関する質問


もちろん、インフラストラクチャーの安定性やデータベースの稼動に関するこうした懸念の中で、*誰もが*尋ねている*重要な質問がある：


どうやってお金を稼ぐのか？


Apache Kafkaやその他のデータベースを自分で運用している場合、インフラを運用することに長けているだけで、お金を稼いでいるのでしょうか？


どこに、どのようにリソースを投資するかは、収益にとって重要なことだ。


### これは誰の頭痛の種なのか？


もしあなたが一人でやっているのなら、運用、信頼性、アプリ開発......膨大で幅広い専門知識の基盤が必要だ。そのため、人材の採用方法や、チーム全体の構成を計画・構築する方法が変わってくる。


ベンダーと協業したり、プラットフォーム上で構築したりする場合、直接的なプレッシャーは少なくなるが、同時に、彼ら*に何が期待されているのか、そして*あなた*に何が期待されているのかを理解する責任がより重くなる。


適切な専門知識があることを確認してください。もし直接スタッフがいないのであれば、適切なパートナーやサポートプランがあるか？常に誰かがこれらについて考えていること：


* メトリクスとモニタリング
* スケーラビリティ
* コスト削減
* アプリケーション・アーキテクチャ
* クエリの最適化


### 機会損失のコスト


自社のオペレーションに責任を持つのであれば、サービスの信頼性にも責任を持つことになる。トラフィックやデータ量の急増、予期せぬアラート、サーバーのパッチ適用やメンテナンスの実施など、アップタイムの必要性を調整する最終的な責任はあなたにあります。そのすべてを把握する必要があります。



**収益に直結しない作業に忙殺されているようでは、収益につながる機能を提供することはできません。必要なければ、開発者のサイクルを運用タスクに犠牲にしないこと。ROIが理にかなったものであれば、責任の一部をオフロードすることを検討しよう。



### チーム効率に影響を与えるその他の視点


* アリスとボブ vs. Stack Overflow**：あなたが遭遇するすべてのエラーやバグのうち、Stack Overflowにアクセスして解決策を探すことで解決できるものはいくつありますか？そしてそのうちのいくつを、何年も前にその*ものを作り、それについて知っている唯一の人であるアリスとボブが解決しなければならないのでしょうか？これらの答えは、新しい開発者のオンボーディングのアプローチに影響し、彼らがどれだけ早く立ち上がり、価値を提供し始めることができるかに影響する。
* 構築対購入**：この技術を現在のセットアップで動作させるには、どのような投資が必要ですか？それとも、ゼロから始めてスケーラブルで安定したものにするのか？
* gh(T)`**：T機能のGitHub**というのを聞いたことがあるかもしれない。これはGitHubで技術（Apache KafkaでもPostgresでも何でも）を検索し、その技術に関連するリポジトリがいくつあり、どれだけの開発者がその技術にコミットしているかを特定するものだ。これにより、その技術のエコシステム・スコアがわかる。このスコアとその重要性を理解できれば、その技術分野のエキスパートを直接雇用するのがどれだけ簡単か、あるいは雇用してトレーニングする必要があるかどうかがわかるだろう。


## 巨人の肩の上に築く：統合、ツール、オープンソース


我々は見てきた：


* あなたの決断がアプリに与える影響
* チームはあなたの決定によってどのような影響を受けるか


では、もう少しズームアウトして、技術部門全体（エンジニアリング、オペレーション、DevOps）が、あなたの意思決定やソリューション構築のアプローチによってどのような影響を受けるかを考えてみよう。


そして、ソリューションの構築に関しては、巨人の肩の上に構築することが鍵となる。エコシステムによって既に提供され、準備され、待機しているものは何か？あなたは、その確立された基盤を活用し、それを使って稼ぎ、節約することができる（そう、それはお金に帰結する。）


### プロプライエタリ対オープンソース


賢明なソフトウェア・アーキテクトは、プロプライエタリ・ソフトウェアやツールのライセンスがいかに厄介かを知っている。別のクラウドや別の技術提供の利点を探りたい場合、それは難しいかもしれない。バックアッププランがあることを確認する必要がある。


### 観測可能性


観測可能性を最初からアーキテクチャに組み込む。観測可能性は必須*である。アプリチームやエンジニアリング部門が他のチーム（例えばDevOpsやセキュリティなど）に相談することなく決定を下すと、他のチームやプロセスに盲点が生じる。そして、チームが盲目的に働くと、問題が発生する。


### セキュリティとガバナンス


**ストリーミング・データ** - リアルタイムで収集されたデータや、最新のビジネス状況を反映するダッシュボード - は、今日のハイテク環境では金よりも価値がある。そして、顧客の個人情報やデータ利用の取り扱いに確信が持てるようにすることが重要です。


品質管理の重要性を見落としてはならない。テストは、機能的なインフラストラクチャの重要な部分です。災害がなければ、災害復旧計画は基本的に単なるおとぎ話に過ぎないと言ったのを覚えているだろうか？テストがなければ、システムの安定性は冗談に過ぎない。


## 総所有コスト


そして、今度はズームアウトする：


* あなたの会社とその全体的な拡張性
* より広い業界におけるあなたの会社の位置
* あなたがその業界の限界に挑戦する方法


インフラで最もコストがかかるのは、キーボードと椅子の間です。スプリントチームが十分に効果を発揮し、価値を提供できるようにすること。あなたは彼らのためにお金を払っている。あなたがお金を払っている他のものと同じように、賢く、元を取りましょう！


**ネットワーク、ツール、なんでもそうだ。サーバーに値段がついていても、会社や顧客の使用パターンを知らなければ、そのサーバーがコストに見合っているかどうかわかりません。


**ツールを理解する。** 手元に十分な専門知識があるかどうかを知る。どのような投資をすべきか知りましょう。そして、大手プロバイダーに実験用の無料クレジットを求めることを恐れないでください！


### 課金パターン


名前を挙げるわけではないが、新興企業にはちょっとしたトレンドがあり、成長のためにどのように規模を拡大するかということがある。


年間コミットモデルでは、特定の機能へのアクセスに対して料金を支払う。スケールアップは可能だが、基本的にはライセンス料だ。


近年では、ライセンスではなく、利用ベースのプロバイダーに移行することで、これらのコストの一部を取り除く方が収益性が高くなっている。アプリケーション・オペレーション・レベルでは、コミットしたアクションや重複したアクションに応じて料金を支払う。これは最初のうちはうまくいくが、非常に*速く、そしてしばしば予想外にスケールする。


解決策は、**予約済みインフラストラクチャ**だ。キャパシティプランニングとワークロードの把握はお客様の責任です。そのニーズを満たすプランを購入する。そうすることで、価格予測がより管理しやすくなります。


## 多くの質問


私たちは、あなたの会社で何がうまくいくかを言うことはできません。それを言えるのはあなただけです。しかし、ソフトウェアアーキテクトのレンズを通して、あなたが質問すべきことを垣間見ることができれば幸いです。


* イベント・ストリーミング・プラットフォームの選択をどのくらいの頻度で再評価すべきか？
* プロプライエタリなソフトウェアやソリューションは、いつオープンソースと比較して意味があるのか？
* どの程度アウトソースできるか？どの程度アウトソースすべきか？
* 自主管理はいつ意味があるのか？


### これがその方法だ


#### 今日、最初の一歩を踏み出そう

Aivenのエキスパートにチャットを予約し、当社のマネージド・データ・インフラストラクチャが必要かどうかをご確認ください。

[今すぐデモを予約](https://aiven.io/book-demo)
### もっと読みたいですか？


* [イベントストリーミングのためのAiven](https://aiven.io/solutions/aiven-for-event-driven-architecture)についてのページをチェックし、私たちとの簡単なデモスロットの予約を検討してください！
* イベント・ストリーミングはモノのインターネットにどのようにフィットするのでしょうか？私たちの成功事例の一つであるEveractive社を見てみましょう - そして、[彼らの経験がどのようにあなたの利益になるか](https://aiven.io/case-studies/everactive-relies-on-aiven-for-iot-data)
* [イベント・ストリーミングの問題解決](https://aiven.io/blog/solving-problems-with-event-streaming)についてのブログ記事もご覧ください。



Aivenと私たちのサービスに関する最新ニュースや、オープンソースに関するちょっとした情報を入手するには、[月刊ニュースレターを購読](https://aiven.io/newsletter)してください！Aivenに関する日々のニュースは、[LinkedIn](https://www.linkedin.com/company/aiven/)と[Twitter](https://twitter.com/aiven_io)のフィードでご覧いただけます。


また、Aivenのサービスアップデートを知りたい方は、[変更履歴](https://aiven.io/changelog)をご覧ください。