AmazonのN-Tierサービスの複雑さ
サービスAPIの課題とGraAmazonの内情を明かすエッセイで、当時のサービスアーキテクチャーの問題点を指摘。
SQLの問題を解消するために、破壊的変化が必要であるとし、将来のGraphQLに繋がる考え方を示している。
2004年にSteve Yeggeが執筆した論説が、20年ぶりに再び注目されています。この文章は、GraphQLというクエリ言語が登場する8年前に、アマゾンの内部データサービスがシステム複雑性を減らすのか、それとも移動させるのかという問題を指摘していました。
アマゾンの内部データサービスとシステム複雑性
Steve Yeggeは、アマゾンの内部データサービス（顧客マスター、注文マスター、商品マスターなど）がシステム複雑性を減らすのか、それとも別の場所に移動させるのかという問いを提起しています。この論説では、データベースを分割することで「2-tier問題」を解決したものの、アプリケーション開発者に負担を押し付けたと指摘しています。
サービスAPIの失敗とGraphQLの登場
サービスAPIが失敗する2つの理由として、クライアントに全体的なオブジェクトグラフを過剰に取得させることや、サービスオーナーにチャットのような細かい呼び出しを押し付けることが挙げられています。その解決策として、クライアントにAPIを抽象化する新しいクエリ言語の構築が提案されています。それが現在のGraphQLであり、Facebookは2012年にこの問題を解決するために導入しました。
関連記事と背景
この論説は、2004年にアマゾン内で執筆され、2006年に一時的に公開されたものの、CTOの Werner Vogels により取り下げられました。その後、旧サーバーのバージョン履歴に残る形で保存されていました。関連記事として、2004年の『It's Not Software』や2011年の『The (Google) Platforms Rant』も挙げられています。
まとめ
Steve Yeggeの論説は、現代のシステム設計においても重要な指針となっています。特に、GraphQLの登場は、この論説が予測した解決策として現れることになりました。
原文の冒頭を表示（英語・3段落のみ）
Author’s note
I am super sad for the industry that Werner Vogels asked me
to take this one down. It would have made such a splash. I published it
※ 著作権に配慮し、引用は冒頭3段落までです。続きは元記事をご覧ください。