Open3
AWS - 定番業務システム14パターン設計ガイド

1章
冗長構成を構築する。
仮想サーバのテンプレートとなる、「Amazon マシンイメージ」(AMI)を利用して、複数の仮想サーバーをまとめてセットアップする。
冗長構成の注意ポイント
- セキュリティグループを分けることで、webサーバにはELBからしかアクセスできないようにする必要がある。
- セッション維持のため、スティッキーセッションを有効にする必要がある。
- httpsプロトコルにする。ELBのリスナー設定でロードバランサのプロトコルをHTTPSにして、インスタンスをHTTPにすることでSSLターみネーションにすることができる。
- ヘルスチェックをする。5秒間隔で非正常が2回とすると良い。
- レスポンスのタイムアウト時間。ELBからサーバへの問い合わせに時間がかかると、クライアントに504を返すため注意が必要。
RDS利用時の注意
アクティブ-スタンバイ構成にして、マルチAZにしてすることでアクティブなDBサーバーをマスターとして、スタンバイサーバーをスレーブとして同期レプリケーションする冗長構成にできる。
- 適宜スナップショットを取る。初期セットアップが終わったらスナップショットを取るなど。バックアップでは保持期間が最大でも35日なため、恒久的に取っておきたい場合はスナップショットが良い。
- AWSによるメンテナンス。RDSは数ヶ月に1回マイナーバージョンアップが自動実行され、30分間停止する。
- マルチAZを利用するとデータの更新処理にかかる時間が長くなる。マスターで更新したデータをスレーブに同期させる処理が終わるまで、マスターは次の処理を実行できない。
- マスターDBと異なるAZにあるEC2インスタンスからアクセスする際に遅延が発生する。
Auto Scaling時の考え
インメモリーのキャッシュと高速RDB
データアクセスの時間が長いことが多いので、データアクセスの遅延を小さくする仕組みも作る必要がある。
そこで以下の方法を取ることが多い
- ElastiCacheを使う。
- MemcachedとRedisをよく使う。
- これらとRDBの使い方の違い - 複数のプロセスで同じデータを更新すると一貫性維持できなくなるので、そういったデータはRDBに保存すると良い。
- 高速なRDBの利用。
- MySQLではなく、RDS for Auroraを使うメリットはp50に記載。
スケーリングについて
スケールには2種類がある。
- 事前にスケールするタイミングが分かっている状態
- タイミングは分からないが、状況に応じてスケールする必要がある状態
2の場合、CloudWatchと併用する。
インスタンスを監視して、CPUの不足を感じると自動でスケールするようにできる。
これは、CPUの閾値やリクエスト数などを監視して変動させる。
Auto Scalingグループには、3つの設定が必要になる。
- CloudWatchのモニタリング設定。監視項目と閾値で、インスタンス数を増やすトリガーと、減らすトリガーを作成する。
- スケーリングポリシーの最小サイズと最大サイズのみを設定する。インスタンス数を変動させたいタイミングでコマンドラインツールからインスタンスを起動・停止する。
- EC2インスタンス購入オプションの選択。オンデマンドインスタンスとスポットインスタンスの2種類から選択できる。オンデマンドインスタンスは確実に起動できる通常価格のインスタンス。
Auto Scalingグループで利用するAMIの作成での考慮すべき点
- アプリケーション環境のデプロイ。実行環境を用意するために、デプロイ済みAMIを毎回作り直す必要が出てしまうため、インスタンス起動時にデプロイを自動実行する仕組みを用意してスクリプトを実行するのが良い。
- インスタンス終了に備えてデータを退避する仕掛けを作っておく。そしてEBS領域に格納しておく。
リージョン間で障害が発生した場合
2種類の対応がある。
- 障害発生時に自動切り替えする方式 - コストは高いが短いダウンタイム
- バックアップデータからサーバーを作成する方式 - コストは低いが長いダウンタイム

2章
ファイルストレージに関する一般的な構成についての章。
3つのパターンを構築している。
オンプレ環境からのバックアップ方法
- S3にコマンドラインでファイル転送
- EC2にDRBDで同期
- S3に自動バックアップ
AWS Storage Gatewayの利用
AWS Storage Gatewayを使うと、オンプレの環境にVMサーバとして立ち上げたサービスから、AWSの設定をしバックアップを送信することができる。

3章
スモールスタートに対する、データ収集基盤の低コスト構築について。
Redshiftにデータを集約してBIツールで取得するという方法を行う。
Redshift
RedshiftはGoogle Cloudで言うところの「BigQuery」に当たるもの。
列方向の検索にも対応し、高速な検索が可能なスケールしやすいDWHとなっている。
しかし、以下の点で異なる。
- BigQueryはサーバーレスアーキテクチャを採用しており、クラスターの管理が不要
- RedshiftはMPP(Massive Parallel Processing)アーキテクチャを採用し、クラスターのサイジングが必要