この記事について

この記事ではエンジニアリングに携わっていない人でも理解すると便利と思うシステム構築の知識についてまとめました。この記事を通じて少しでもシステム構築の楽しさを感じていただければ幸いです。

なお、極力知識がなくても理解できるように書いたつもりでありますが、必要に応じて以下の記事も合わせて読んでいただけますと幸いです。

今回は、代表的な以下の５つの機能・要素を紹介します。

• クライアントアプリ
• ロードバランサ
• キャッシュ
• バッチ処理
• 非同期処理

クライアントアプリとサーバーの関係

インターネットを介してデータを配信したり、ユーザーの情報を中央集約するシステムの場合、必ず必要とされるのが中央管理するサーバーと、クライアント端末に入れるクライアントアプリです。

システムというと、巨大なサーバの塊をイメージしますが、スマートフォンやPCに入れられるクライアントアプリも大切なシステムの一部です。

それぞれの関係は以下の図のようになっています。

クリックすると拡大できます

サーバがないと、データの中央管理や利用者への更新データ配信などができません。同じようにクライアントアプリがないと、端末はサーバにアクセスしてデータをもらったり、受け取ったデータをユーザーが利用しやすいように画面出力したりすることができません。

クライアント端末のアプリも立派なシステム構成上の1要素と言えます。

ロードバランサを使ったシステムの負荷分散と冗長化

ロードバランサは負荷分散や冗長化を目的としたシステム上の機能です。

例えば、ロードバランサを利用していない以下の図のようなシステムをみてみましょう。

クリックすると拡大できます

このシステムのサーバはたった１台で複数のクライアント端末に対してデータ配信・データ保存などを行っています。もしも、100、1000と非常に膨大な数の端末からアクセスを受け付けるとなると、１つのサーバだけでは処理しきれないという問題が発生します。

同時にこのシステムの場合、単一サーバ故にこのサーバが故障してしまうと全てのシステムが停止してしまいます。１つのサーバが故障するだけで、システム全停止してしまう状況は大きな問題と言えます。

このような問題を対応するために実装するものがロードバランサです。ロードバランサを実装したシステムは以下のような構成になります。

クリックすると拡大できます

上の図のように、クライアント端末からのアクセスはロードバランサ１次受けします。アクセスを受け付けたロードバランサは、バックエンドとして全く同じ機能を持つ複数のサーバのリストを持っています。ロードバランサは登録されたバックエンドのサーバの負荷状況を配慮しながら適切なサーバを選んで端末より受け付けた処理を割り振ります。

クリックすると拡大できます

さらに、ロードバランサは、登録されたサーバの死活状況も確認しています。例えば下図のように１つのサーバで障害が発生した場合、ロードバランサはアクセス先候補から障害が発生したサーバを外します。以降クライアントからアクセスを受け付けた場合、障害が発生していないシステムのみに割り振るように対応します。

クリックすると拡大できます

このようにロードバランサは単一サーバに負荷を偏らせたり、一つのサーバが障害が発生した時に全てのシステムが停止しないように負荷分散、冗長化を行ってくれます。

DNSサーバを活用したロードバランサの負荷分散

おそらくここまでの説明を受けて、ロードバランサがシステムダウンした場合どうするのか？という疑問を持った方もいるのではないでしょうか。このリスクを回避する手段としてDNSサーバを活用します。

DNSサーバは、sample.comといったドメインが、どのIPアドレスと対応しているのかを知っており、クライアントは当該サーバにアクセスする前に、最初にDNSサーバに問い合わせてIPアドレスを教えてもらいます。

DNSサーバには、指定ドメインに対して、複数のIPアドレスを登録することができます。複数のIPアドレスを登録されていた場合、登録されたIPアドレスの中から１つを選んでクライアントに伝えます。

この機能を利用してロードバランサの負荷分散が行えます。以下の図のように、DNSサーバに複数のロードバランサのIPを登録させます。DNSサーバはクライアントに対して一つIPアドレスを選んで返却します。このようにして複数のロードバランサを並行稼働させることができます。

クリックすると拡大できます

上の図はDNSサーバ、ロードバランサを使って負荷分散をしたシステムの一例です。このシステムは、バックエンドのシステムについてもDNSサーバを利用してロードバランサの負荷分散を行っています。このように組み合わせていくとちょっとの負荷やシステム停止にも強い強固なシステムになっていきます。

DNSサーバの負荷分散

なお、DNSサーバについても負荷分散が可能です。DNSサーバは実はクライアント端末に複数の候補が登録されていたり、DNSサーバ自身も複数の親DNSサーバの候補を持っています。

クリックすると拡大できます

このようにして、全てのシステムの要素で負荷分散が行うことができます。

キャッシュによるアクセス速度の高速化

キャッシュはシステムのアクセス速度の高速化をサポートします。

例えば以下の図のシステムをみてみましょう。

クリックすると拡大できます

このシステムは何階層ものバックエンドサーバが存在しています。このシステムのクライアントがサーバに対してアクセス要求をすると、毎回バックエンドサーバにアクセス要求を行い、アクセスを受けたバックエンドサーバはさらに後ろに存在するバックエンドサーバに...とアクセスをしていきます。このような構成をしていると、毎回毎回最深部のバックエンドサーバの処理完了まで待つことになり、クライアントへのレスポンス速度は遅くなってしまいます。

この問題を解決するために実装されるのがキャッシュです。

キャッシュの仕組み

キャッシュの仕組みは以下の図のようになっています。

クリックすると拡大できます

クライアント端末がフロントエンドサーバにアクセス要求を初めてした際に、バックエンドサーバにデータ取得のアクセスを行います。データを取得した際に、クライアントにレスポンスを返すと同時にバックエンドサーバから受け取ったデータをキャッシュという形でフロントエンドサーバ内で保存します。

再度クライアントからアクセスがあった場合、フロントエンドサーバは今度はバックエンドサーバにデータ取得のアクセスは行いません。先ほど保存したキャッシュを利用してクライアントにレスポンスを返します。このようにして、バックエンドサーバを介さずにクライアントのレスポンスを行い、アクセススピードを向上させているのです。

なお、キャッシュには必ず有効期限が設けられています。キャッシュの有効期限が切れた場合、フロントエンドサーバは再度バックエンドサーバにアクセスして新しいデータを取得します。その際に古いキャッシュは削除し、新しいキャッシュを保存します。このようにして古いデータがいつまでも残り続けないようにしています。

バッチ処理を使った定期処理

ここまで、全ての処理はクライアント端末の動作をキックにして動いていました。しかしながら、クライアントの操作だけでシステムを運用することに課題があるケースも多々あります。

以下のケースはショッピングサイトのシステムです。ユーザクライアント端末がショッピングサイトWEBサーバを通じて購入記録を登録していき、ショッピング管理者端末が、総売上管理ツールWEBサーバを通じて総売上データを取得しています。

クリックすると拡大できます

このシステムには問題があります。ショッピング管理者が総売上を取得する際、購入記録データベースからデータを取得しますが、その際に毎回巨大な購入履歴データを取得して集計する必要があります。この状態では、総売上を取得する際に毎回時間のかかる計算を行ってしまうので、総売上管理ツールWEBサーバに負荷をかけるだけでなく、総売上のクライアント端末での表示にも時間がかかってしまいます。

この問題の解決策としてあげられる実装がバッチ処理の実装です。バッチ処理とは定時実行など、クライアントアクセス以外のキックで処理を開始するプログラムです。

それでは、バッチ処理を実装した以下の図をみてみましょう。

クリックすると拡大できます

このシステムでは、定期的に売り上げを集計する売上集計バッチサーバが存在します。このシステムはクライアント端末の処理とは無関係に定期的に集計処理を行います。まず購入記録管理データベースにアクセスし、前回アクセスした時の購入記録からの差分を取得します。取得した購入記録を集計し、総売上管理データベースのデータも取得して足しあげ、総売上管理データを更新します。

このように総売上管理データがすでにデータベースとして作られているので、総売上管理ツールWEBサーバは毎回購入記録管理データベースにアクセスして計算する必要がありません。システム負荷やレスポンス遅延の心配もなく、総売上データの利用ができます。

非同期処理を利用したデータ保存処理の効率化

非同期処理を説明する前に、コンピュータのデータ保存について解説します。コンピュータのデータ保存には短期記憶と長期記憶という二つの種類があり、それぞれ以下のような特徴があります。

このように、短期記憶と長期記憶はお互いの弱点を補完しあう関係になっています。データ管理というとデータベースをイメージしますが、データベースについても短期記憶に特化したデータベースと長期記憶に特化したデータベースがあり、システム設計においてはこの２つをうまく使いわける必要があります。

次の図は長期記憶が必要なデータの保存を目的としているために長期保存用のデータベースを使っている例です。

クリックすると拡大できます

上の図のシステム構成には課題があります。クライアントから大量の書き込み処理のアクセスが会った際に、長期保存用データベースに負荷がたまりボトルネックになるリスクがあります。

この問題を解決するために、短期記憶が得意なデータベースを活用した非同期処理が考えられます。

以下の図が短期記憶データベースを活用した非同期処理システムの構築例です。

クリックすると拡大できます

クライアントから受け付けたデータ保存処理はいったん短期記憶が得意な仮登録データベースに保存されます。クライアントへはいったん仮登録データベースの保存を持って保存完了というレスポンスを返します。仮登録データベースは短期記憶が得意ではありますが、長期的な保存はできません。そこで、本登録バッチサーバを用意して定期的に仮登録データベースに登録されたデータを引き出し、本登録データベースサーバに登録していきます。

このように本来は切り離すことができない一連の処理をすべてクライアント端末と同期的に行うのではなく、非同期的に処理をさせる仕組みのことを非同期処理と言います。

なお、上の図は短期記憶データベースとバッチ処理を利用した非同期処理の構築例でしたが、非同期処理はメッセージキュー（MQ）というサーバアプリケーションを使っても実装することができます。

メッセージキューを稼働させたメッセージキューサーバは非同期処理を実現するため、非同期処理実行を行うサーバに処理命令を実施するサーバです。

メッセージキューを使うような場合、以下のようなシステム構成になります。

クリックすると拡大できます

基本的な構成はバッチと短期記憶データベースを活用したものと一緒です。クライアント端末のアクセスを受け付けるWEBサーバはメッセージキューに本登録ジョブサーバへの登録処理の依頼します。WEBサーバはメッセージキューに登録処理依頼を完了した時点で処理終了としてしまいます。

メッセージキューは本登録ジョブサーバに本登録の依頼があったことを伝えます。依頼を受けた本登録ジョブサーバは本登録用のデータベースに本登録を実行します。

このように効率的にデータ保存処理を実装していきます。

終わりに - さらなる発展として -

今回は５種類のシステム構築のパターンを紹介しました。

こんな複数台もサーバを組み合わせたシステム、大規模なシステムじゃないと縁がないよ！と思うかもしれませんが、近年ではFirebaseのように手軽に構築することができるサービスも増えました。※今後Firebaseの実際の使い方についても記事を書いていければと思います。

なお、実際に各種システムはどんな風に活用しているだろうと思っている方向けに今後システム構築例も紹介していこうと思います。是非そちらも読んでみてください。

この記事を通じて、普段業務利用しているツールに課題があるときに、何が原因なんだろうと考える時のお役にたてたり、少しでもシステム構築の面白さを感じていただければ幸いです。最後まで読んでいただきありがとうございました。

Photo by Matthew Henry on burst