システムデザインを学ぶ - 初級編

はじめに

こんにちは！！株式会社Inner Resourceの檜野です。

今回は、個人的にシステムデザインについて勉強した内容を基に、ユーザー数がゼロから爆発的に増えた際にどのような技術を使用して対策をしていくのかを紹介します！

ロードバランサ

概要

複数のサーバーにトラフィックを均等に分散させる装置です。

なぜ使用するのか？

一つのサーバーにトラフィックが集中すると、サーバーに高負荷がかかり、レスポンスが遅くなったり、ダウンしたりする可能性があります。ロードバランサを使って効率的に負荷を分散させ、各サーバーのリソースを最適に使用する事が必要です。

AWS Elastic Load Balancing (ELB)

アプリケーションロードバランサやネットワークロードバランサがあり、HTTPやTCPトラフィックの分散が可能です。

サーバーやデータベースのスケーリング

概要

コンピューティングリソースを追加する方法です。スケールアップ（垂直スケーリング）とスケールアウト（水平スケーリング）の2つのタイプがあります。

スケールアップ

スケールアップは、サーバーのメモリ数を上げたり等スペックを上げる事です。
スペックは無限に上げる事は現実的に出来ないので、スケールアウトの施策が取られる事が多いです。

スケールアウト

今動いているサーバーの負荷に応じて、サーバーの台数を増やし処理を分散する事です。

なぜ使用するのか？

ユーザー増加や、急激なトラフィック増加で、負荷が増加した場合に、システムが応答時間を保ちつつ正常に動作し続けるためには、リソースを柔軟に拡張する必要があります。

AWS Auto Scaling / Amazon Aurora Auto Scaling

Auto Scalingを使ってEC2インスタンスをスケールさせたり、Amazon Auroraでデータベースのスケーリングが出来ます。

データベースレプリケーション

概要

データベースレプリケーションは、データベースを複数の場所に複製する方法です。また書き込み専用と、読み込み専用で分けたりします。

なぜ使用するのか？

書き込みと、読み込みを分ける事で読み込みの負荷を軽減出来安定させる事が可能です。
また複数の場所にDBがあるので、災害時のデータの担保性も上がり、1つのサーバーが落ちても稼働し続ける事が可能です。

Amazon Aurora DB Clusters / Amazon Aurora Read Replicas

読み取り専用の複製を作成して、読み取りクエリを分散出来ます。

データベースシャーディング

概要

データベースシャーディングは、データを複数のデータベース（シャード）に分割して保存する手法です。簡単に言うと特定数のレコード毎に分割して別々のデータベースに保存します。各シャードは異なる部分のデータを保持し、分散された環境で並列に処理を行います。

なぜ使用するのか？

データベースのサイズが大きくなり、1つのデータベースでは処理が困難になった場合や、同時に多くのトラフィックが発生する場合に、シャーディングを使用することで処理を分散し、パフォーマンスを安定させる事が出来ます。

Amazon Aurora

Auroraで出来るらしいが試した事がないので詳しくはわからない

キャッシュ

概要

キャッシュは、よくアクセスされるデータを一時的に保存するメモリ領域です。

なぜ使用するのか？

データベースやAPIへのリクエストを減らし、負荷を軽減出来るのと、レスポンスを高速化する事が可能です。

Amazon ElastiCache

MemcachedやRedisが使え、頻繁にアクセスされるデータのキャッシングに使用します。

CDN(Content Delivery Network)

概要

CDNは、地理的に分散したサーバーを利用して、ユーザーにコンテンツを高速かつ効率的に配信するネットワークです。

なぜ使用するのか？

コンテンツの配信をユーザーの地理的な場所に最も近いサーバーから行うことで、遅延を減らし、サイトのパフォーマンスを向上させます。

Amazon CloudFront

グローバルなキャッシュネットワークで、静的および動的コンテンツを効率的に配信します。

NoSQL

概要

NoSQLは従来のリレーショナルデータベースとは異なる形式でデータを保存するDBです。Key-Value型等アプリによって異なります。

なぜ使用するのか？

大量の非構造化データの高速な読み取り・書き込みが可能だったり、高い柔軟性、拡張性を持っています。

Amazon DynamoDB

NoSQLでありサーバーレスなDBです。高速な読み取り・書き込みはもちろん、サーバーレスなので高い柔軟性、拡張性を実現する際にサーバーの再起動や、アップデートは必要ありません。

最後に

• 今回紹介したもの以外にも使える技術は色々あるはずです。
• このようなシステムデザインや、アーキテクチャについて知見を深めた後に、適当なアプリを想定した技術選定を考える会みたいなものを会社でやれると凄くいいなと思っています！
• そして最終的には既存のアプリを、今の構成を考えず、新しく作るならどうするかを話し、その差分から改善案を出せたりすると最高だという感じです！！