Webアプリケーションのアーキテクチャについて理解しておきましょう。
各アーキテクチャを理解しておくことで、Webアプリの設計やデータへのアプローチ方法などが適切になるでしょう。
1. モノリシック vs マイクロサービス
モノリシック・アーキテクチャ
一つの大きなコードベースで全ての機能を実装する手法です。
デプロイは簡単だけど、スケーリングやメンテナンスが難しい。
SPAと言われるアプリ構成で、単一機能などの場合に有効なアーキテクチャ。
マイクロサービス・アーキテクチャ
各機能を独立したサービスとして分割。
スケーラビリティや障害対応が向上するが、デプロイと管理が複雑。
単一機能を1つのマイクロサービスとして構築して、それらを組み合わせていく事で大きなサービスを組み立てていく手法。
2. クラウドネイティブアプローチ
コンテナ
Dockerを用いてアプリケーションをコンテナ化し、一貫した環境を提供。
Kubernetesを使ってコンテナをオーケストレーションし、スケーリングと管理を自動化。
仮想環境でのDockerは、開発環境として便利に利用できます。
コンテナを自身で構築できるようになると、アプリケーションでの構築できるレベルの幅が無限に広くなります。
サーバーレス
AWS LambdaやGoogle Cloud Functionsを使って、インフラの管理を省略。
イベントドリブンなアーキテクチャが主流。
サーバーレスを利用すると、コスト軽減や、サーバー依存しないための安定したアプリケーションが提供できるようになります。
ただ、難点としては、サーバーレスで使用するアーキテックチャの仕様に依存しなければいけないので、思った事が思った通りにできない事も、しばしば発生します。
3. API設計
RESTful API
一般的なAPI設計手法。リソースをエンドポイントとして表現し、HTTPメソッド(GET、POST、PUT、DELETE)を使用。
PHP、Python、Java、Ruby、Go、などなど好きな言語をエンドポイントとして設置することができるので、かなり自由度が高いですが、エンドポイントを細かくすればするほど、APIアクセス数は膨らむので、
大規模アクセスサービスなどの場合は、CDNや相応のキャッシュサービスと連動して構築することも視野に入れましょう。
GraphQL
クライアントが必要なデータのみを取得可能。複雑なクエリや型システムのサポートがある。
Facebookが開発をしているOpenアーキテクチャで、データベースとフロントエンドを直結させる事ができるインターフェイス的なAPIシステムです。
データベースへのアプローチがかなり柔軟にできるため、Javascriptベースで大規模なデータベースを利用することも可能になります。
しかし、事前設計をしっかり行わないとセキュリティが弱くなるかもしれません。
4. 認証と認可
JWT(JSON Web Token)
トークンベースの認証。セッション管理を必要とせず、スケーラブル。
Restful APIのデータ送受信をJSONにする事で、key値や、データ個数などを柔軟にやりとりできるようになります。
以前は、XMLでのやり取りが主流でしたが、namespaceなどのセキュリティ属性や、データ自体の可視性が複雑になりすぎるなど、扱いづらい点が多かったですが、JSONであれば、手動でデータの構築をすることも可能なので、運用の負担軽減にもつながるでしょう。
OAuth 2.0
標準化された認可フレームワーク。第三者のアプリケーションがリソースにアクセスする際に使用。
GoogleやFacebook、X(旧:Twitter)などがメジャーですが、すでにユーザーが保持している主流なアカウントでのログインを紐づけることで、ユーザーデータベースを持たなくてもサービス利用を可能にする事ができる上、
セキュリティ漏洩の心配が無くなるなどのメリットも大きいです。
5. デプロイメントとCI/CD
CI/CDパイプライン
継続的インテグレーション(CI)と継続的デリバリー(CD)を通じて、コードの品質とリリースの効率を向上。
Jenkins、GitHub Actions、CircleCIなどのツールを使用。
オートデプロイなどは、開発したアプリケーションを、必要最低限のコードチェックや挙動チェックなどを行い、問題がなければ即座にデプロイして、アプリ更新を迅速に公開する事ができるようになります。
ソースコードのチェックをするシステムをLint(リント)という場合もあり、Lintツールはたくさんのフレームワークで用意されているので、適したLintツールを繋いなレルと、不具合などを極力無くすアプリ開発ができるようにもなります。
インフラストラクチャー・アズ・コード(IaC)
TerraformやAWS CloudFormationを使って、インフラをコードで管理。
再現性とスケーラビリティが向上。
DockerComposeなどと連携して、サーバー環境(インフラ)を設定定義ファイル(manifest.jsonや、docker_compose.yml等)で設置するようにすることで、開発環境、テスト環境、本番環境などの構築を一元設定する事ができ、
その後の変更点なども効率的に管理する事ができるようになります。
6. パフォーマンスとスケーラビリティ
キャッシュ
RedisやMemcachedを使って、データベースの負荷を軽減。
CDNs(Content Delivery Networks)を使用して、静的コンテンツの配信速度を向上。
CDNサービスは、コストが高いので、サーバーでのメモリキャッシュの仕組みや、ネットワークRaidシステムなどを構築することで、簡易にキャッシュ化する事はできます。
最も簡易な方法としては、同一クエリで同一返答をする情報をJSONテキストデータや、簡易データベーステーブルなどで構築することも可能です。
スケーリング
垂直スケーリング(より強力なサーバーへのアップグレード)と水平スケーリング(複数のサーバーの追加)の組み合わせ。
オートスケーリングを使用して、需要に応じたリソースの割り当てを自動化。
AWSなどのクラウドサーバーを前提にしていますが、オンプレミスサーバー構成の場合でも、水平スケーリングは、サーバー負荷閾値と、ロードバランサーを使って構築できる昔からの手法なので、バックエンドエンジニア知識としての水平スケーリング手法は理解しておくこと、それができる設計が重要になります。
垂直スケーリングは、単純にサーバースペックを上げるだけの作業なので、アクセス過多などに対応する場合は、できるだけ水平スケーリングを心がけましょう。
7. ロギングとモニタリング
集中ログ管理
ELKスタック(Elasticsearch、Logstash、Kibana)やSplunkを使用して、ログを収集・分析し、異常検知やトラブルシューティングを容易にする。
バックエンドエンジニアのメインの仕事と言ってもいい、ロギングによって、想定閾値オーバーの場合のサーバーメンテナンス対応が必要になります。
Webアプリケーションに最大何人同時にアクセスする事が、正常動作できるレベルなのかをまずは設定しておくと、閾値が作りやすくなるでしょう。
モニタリングとアラート
PrometheusやGrafanaを使って、システムパフォーマンスをリアルタイムで監視。
アラート設定を行い、問題発生時に迅速に対応。
サーバーのリアルタイムモニタリングは、GoogleAnalyticsのようにサーバー状態を正確に見るシステムです。
これにより、アクセスの増加傾向などをリアルタイムに検知して、水平スケーリングなどをリアルタイムに行えるようにしておく事で、サーバーダウンして、サービス停止を防ぐ事が可能になります。
最も避けたい事象は、サービス停止なので、動作するシステムを前提に閾値を設定しましょう。
あとがき
これらの要素(単語やツール)を理解し、適切に実装することで、堅牢でスケーラブルなWebアプリケーションを構築することができます。
時間に余裕があるのであれば、是非紹介したツールを事前に軽く触っておくことをオススメします。
0 件のコメント:
コメントを投稿