システムの構成要素 — 内製する範囲と外部サービスに委ねる範囲

この記事は、 Web アプリを構成する4 つの要素を扱います。

そのうち 3 つは内製（自分の側で開発して用意すること）し、残る 1 つは外部サービスとして利用します。

内製と利用の境界は、この枠の境目にあります。

Web アプリは 4 つの構成要素に分かれる

構成要素は、フロントエンド（frontend）・バックエンド（backend）・データベース（database）・外部サービス（external service）の 4 つです。

データベースと外部サービスにつながるのはバックエンドで、画面から直接はつながりません。

この 2 つが動くサーバー（server。電源が入ったままで、他のコンピュータからの要求をいつでも受け付けられるコンピュータ）は、利用者の端末とは別のコンピュータです。

4 つ目の外部サービスだけは内製せず、他社が運用しているものを利用します。

上の枝の 3 つは実装が自分の側にあるので、直すのも自分です。

データベースだけは製品を選んで運用する形になりますが、動かなくなったときに手を入れるのは自分の側です。

外部サービスだけは、障害が起きても自分では直せず、他社の復旧を待つことになります。

何を委ねるかを決めることは、自分では直せない範囲を決めることでもあります。

構成要素は 4 つ、境界は 1 つ

Web アプリは、フロントエンド・バックエンド・データベース・外部サービスの 4 つに分かれます。

前の 3 つは内製し、外部サービスだけは他社が運用している機能を利用するので、実装を用意する側と障害に対応する側はこの境界で切り替わります。

外部サービスは内製せず、API 経由で利用する

確認メールの送信や決済のように、自前で用意すると負担の大きい機能は外部サービスに委ねます。

外部サービスを呼び出すときに従う決まりがAPI（Application Programming Interface。プログラム同士がデータをやり取りするための約束事）です。

外部サービスに移るのは真ん中だけで、依頼と確認は自分の側に残ります。

自分の側に残るのは、依頼を送るところと、返ってきた結果を確認するところだけです。

内製すると、機能そのものに加えて、その維持まで自分の担当になります。

委ねた場合でも、依頼を送ることと結果を確認することは自分に残ります。

外部サービスに移るのは実装だけです。

外部サービスと外部 API

呼び出す相手を外部サービス、呼び出し口を外部 APIと書き分けることがあります。

指しているものは同じで、サービスとして見るか、呼び出し口として見るかの違いです。

構成要素ごとに、処理の成否は独立して決まる

1 つの操作が、複数の構成要素にまたがることがあります。

予約の確定はデータベースへの書き込みで決まり、確認メールの送信は外部サービスへの依頼で決まります。

予約が確定するのは、データベースに書き込めた時点です。

確認メールの送信は、そのあとに外部サービスへ依頼する別の処理です。

メールが届かなくても、確定した予約は残ります。

この切り分けは、不具合の調査でそのまま使えます。

「予約が入っていない」と「確認メールが届かない」では、確かめる構成要素が違います。

前者はバックエンドとデータベース、後者は外部サービスへの依頼を確かめます。

上の枝が確定、下の枝が通知で、片方が失敗しても、もう片方はそのまま残ります。

成否は構成要素ごとに決まる

1 つの操作が複数の構成要素にまたがるとき、処理の成否はまとめて決まりません。

予約はデータベースへの書き込みで確定し、確認メールは外部サービスへの依頼で決まるので、不具合の報告を受けたら、どちらの処理が失敗したのかを先に切り分けます。