シンプルなアーキテクチャを擁護する (2022)

• Waveは70人のエンジニアを擁する$1.7B（2.3兆ウォン）規模の企業（アフリカ向けのモバイルバンキングサービスを提供）
• PostgresベースのPythonモノリスという、標準的なCRUDアプリのアーキテクチャを採用している
• シンプルなアーキテクチャから始め、複雑さを最小限に抑えながら問題を解決することで、エンジニアはユーザーに価値を届ける作業に集中できた
• Stack Overflowは単一体（monolith）をスケールさせ、18億ドルで買収されるほど成功裏に成長した

シンプルなアーキテクチャの効率性にもかかわらず、大半のメディアは複雑なアーキテクチャを好む

• 技術カンファレンスでは複雑なマイクロサービスベースのアーキテクチャに関する発表が多い一方、シンプルなモノリスに関する発表はほとんどない
• 多くの企業が小規模なアプリケーションであるにもかかわらず複雑な技術を模倣し、それによってカンファレンスやHNで人気を集めている
• 私たちが使っているアーキテクチャはあまりにシンプルで、アーキテクチャ図を書く必要すらない

シンプルさを維持する方法

• Waveは同期式Pythonを使っており、これはサーバープロセスがI/Oを待つ間ブロックされることを意味する
• Eventletのような非同期フレームワークも試したが、バグが多すぎて、そのコストは運用上の苦痛に見合わないと判断した
• 複雑さを増やす代わりに、実行時間の長い処理はキューに切り出して処理している
• データレジデンシー規制を順守するため、一部の国ではオンプレミスのデータセンターを運用しなければならない
  • セネガル／コートジボワールはクラウドだったが、ウガンダや他の国々では規制のためオンプレミスが必要だった
  • このような場合、複雑なアーキテクチャよりもシンプルなアーキテクチャのほうがはるかに容易である

購入ではなく構築

• 少人数チームだったため初期にはソフトウェア購入を好んでいたが、重大なバグを解決できない場合には自前のツールを開発した
• 自前ツールの構築は本来引き受けたくない複雑さだが、いくつかの製品カテゴリではかなり広範な調査をしても、自分たちに合う製品を提供できるベンダーが見つからなかった
• コアコンピタンス以外でも、自前ツールを開発し、社内の専門性を維持することが時には必要になる

再考している選択

• RabbitMQ、Celery、SQLAlchemy、Pythonなどの技術選択を再考しており、これらは複雑さを増したり保守負担を高めたりする
• 新しいコードベースを始めるなら、これらの技術選択について慎重に検討するだろう

満足している選択

• GraphQL、カスタムトランスポートプロトコル、Kubernetesなどの選択には満足している
• GraphQLには、自己文書化、コード生成、GraphiQLインタラクティブエクスプローラーなどの利点がある
• GraphQLを使うと、利点が欠点を上回ると考えている
  • 利点
    • 正確な戻り値の型に関する自己文書化
    • 正確な戻り値の型に基づくコード生成により、クライアントの安全性が高まる
    • GraphiQL対話型エクスプローラーによる生産性向上
    • さまざまなアプリ（ユーザーアプリ、サポートアプリ、Waveエージェントアプリなど）がほぼ1つのAPIを共有でき、複雑さが減る
    • 構成可能なクエリ言語を使うことで、クライアントは特定用途向けエンドポイントを多数構築しなくても、1回のパケット往復で必要なデータを正確に取得できる
    • RESTful APIと見なされるものについてのbikeshedding（重要な議題を先送りし、重要度の低いことを延々と議論して時間を費やすこと）をなくせる
  • 欠点
    • GraphQLライブラリは、GraphQLを採用した当時はまだ十分に優れていなかった
    • デフォルトのGQLエンコーディングは冗長であり、多くの顧客が低帯域幅を使っているため、サイズ制限に強い関心を払っている
• Kubernetesは、国ごとのデータセンター運用要件を満たすために使われている

結論

• アプリケーションアーキテクチャを可能な限りシンプルに保つことで、ビジネスに役立つ複雑さがある場所へ複雑性（および人員）の予算を投じることができる
• 複雑さを加える強い理由がない限り、できるだけシンプルに物事を進めるという考え方によって、一般には難しい事業と見なされるアフリカの金融事業を運営しているにもかかわらず、多くのエンジニアがいなくてもかなり大きな事業を築くことができた

[secret3056]

「構築するより購入する」ではなく、「購入するより構築する」が正しい気がします。

Another area is with software we’ve had to build (instead of buy).

[xguru]

あ、強調しようとしていたらタイトルがおかしくなってしまいました。修正しました。ありがとうございます。

[savvykang]

景気サイクルによって流行が変わるのでしょうか？ 流行に関係なく、モノリスで始めるほうが固定費の削減とメンテナンスのしやすさの面で有利です。

[aer0700]

理解しやすいアーキテクチャは、保守もしやすいですよね。

[mhj5730]

私の基準では、どんなサービスでもモノリシックで始めるのがよさそうです。最初からMSAを前提に進めるのはお金の無駄でしょう。

[dhlee0305]

「複雑さが増すと、コスト（金、人、時間...）も増加する」
「シンプルなアーキテクチャで解決できる問題を、複雑なアーキテクチャで解決しようとするな。」

[xguru]

Hacker Newsの意見

• マイクロサービスに関するエンジニアの助言

  • マイクロサービスは性能向上のための戦略ではなく、潜在的なコスト削減戦略およびエンジニアリング調整の戦略である。
  • 水平スケーリング可能なモノリシックアプリケーションとマイクロサービスの間には、特定の機能だけを縮小したい場合を除いて、大きな違いはない。
  • モノリシックアプリでは、アプリの一部だけを縮小することはできない。
  • コスト削減は大規模な段階ではじめて意味を持ち、少なくとも3つのレプリカが必要である。
  • ほとんどの会社における実際の利点は、エンジニアリング面での調整にある。
  • 単一リポジトリを持つモノリシックでは1つのチームが所有して管理できるが、共有モノリスでは誰も所有せず、管理が難しくなる。

• マイクロサービスに関するトーク

  • 一般的な技術カンファレンスでは、マイクロサービスアーキテクチャの複雑さや副作用についての発表はいくつもあったが、シンプルなモノリス構築についての発表はなかった。
  • David Schmitzによるマイクロサービス失敗のコツを扱った講演が印象的で、彼のユーモラスな発表スタイルも魅力的だった。

• 認知バイアスとシンプルさ

  • 人はしばしば何かを付け加えることに意識を向け、単純な解決策を見落とす。
  • 研究では、レゴ構造物にブロックを追加する代わりに取り除くことで問題を解決するほうが、より良い解決策であることが示されている。

• 過剰なエンジニアリングと経験不足

  • アーキテクチャは「十分にシンプルでありながら、必要なだけ複雑であるべき」だが、それを実現するには経験が必要である。
  • IT業界は経験が不足しがちな傾向があり、経験には時間がかかる。
  • 経験の浅いエンジニアやマネージャーは、しばしば不要な技術やメトリクスを使ってしまう。

• ワークライフバランスを重視する会社

  • 製品改善に集中し、残りの時間は個人生活に充てたいと思える会社を探している。

• Dan Luuに関する個人的な経験

  • Dan Luuはブログのファンとの交流に寛容で、ソフトウェアとハードウェアの境界領域に関する専門知識を持っている。
  • 彼は自身の洞察と専門性を惜しみなく共有しており、彼から学ぶことは非常に楽しい経験である。

• シンプルなアーキテクチャの重要性

  • ほとんどの場合に必要なアーキテクチャは、SSL対応ロードバランサー、複数のアプリサーバー、シャーディングされたデータベース、メッセージキューなどの基本的な構成要素である。

• アーキテクチャとエンジニアリングチームの社会的構造

  • アーキテクチャはエンジニアリングチームの社会的構造を反映すべきであり、それを考慮しないと混乱や非効率が生じる可能性がある。
  • 大規模なモノリシックリポジトリとシンプルなアーキテクチャは管理が難しいことがあり、GoogleやMetaのような企業も内部で多くのツールを開発している。
  • アーキテクチャはチーム間の協業を支援することも妨げることもできるため、技術リーダーシップはそれを考慮しなければならない。

• シンプルなアーキテクチャの選好

  • シンプルなアーキテクチャとモノリスはたいてい適しているが、同期IOによる問題が起きないよう注意する必要がある。
  • データ整合性のバグは、金融システムでは避けるべき重要な問題である。

[dangyup]

「David Schmitz のマイクロサービス失敗に関するヒントを扱った講演」のリンクをお願いできますか。

[xguru]

https://www.youtube.com/watch?v=r8mtXJh3hzM です