Open2
データ指向アプリケーションデザイン
システムの信頼性を高めるには
- エラーの可能性を最小限にする = 想定外を最小限にするということ?
- 制約(インタフェース、型)で縛る
- 間違いやすい部分を分離して影響を最小限にする
- 自動化テスト、徹底的にテストをする
- 障害が発生した場合のロールバックをすぐ出来るようにしておく
- 大きな変更を一度にリリースしない
- 監視(パフォーマンス、エラー発生率)から問題、原因特定しやすくする
- 信頼性の劣化→負荷の増大
- 同時接続数、アクセス数、データ量
- 負荷増大したときにどのように対処するかを考慮しておく
- スケーラビリティ
- 負荷に対してコンピューティングリソースをどのように追加するか
- CPUの処理性能が問題になることは殆どない
- どの負荷パラメータが問題を引き起こすか
- リクエスト数
- キャッシュのヒット率
- DBの読み書き比率
- パフォーマンス
- バッチ処理:スループット(1秒あたりに処理できるレコード数、ジョブの実行時間)
- オンラインシステム:レスポンスタイム(リクエストを送信してレスポンスを受信するまで)
- 同じリクエストでも微妙にレスポンスタイムは異なるので分布として測定する(外れ値を除外する為に中央値を利用する)
- バックグラウンドプロセスのコンテキストスイッチ、ネットワークパケットのロスト、TCPの再送、ガベージコレクションによる一時停止、ディスク読み取りを生じさせるページフォルト、サーバラックの機械的な振動、その他多くの要因によりランダムなレイテンシが加わる
- 負荷への対処
- スケールアウト:複数のマシンに負荷を分散させる
- 負荷の増大を検知して自動でコンピューティングリソースを追加する
- 負荷の予測が難しい場合に有効だが手動でスケールさせた方が単純で予想外が起きづらい
- スケールアップ:マシンを強力なものにする
- スケールアウト:複数のマシンに負荷を分散させる
- スケールさせるポイントを見極めるには
- どういった処理が頻繁に行われるのか
- どういった処理が稀なのか
- ここを間違えると無駄になる
- 負荷に対してコンピューティングリソースをどのように追加するか
- AWS RDS
- Auroraとは?
- RDSのDBエンジン(データベースサーバ)の一つ
- DBエンジンとは:データベース管理システム(DBMS)がデータベースからデータを作成、読み取り、更新、削除(CRUD)するために使用する基盤となるソフトウェア部品
- Auroraとは?
- RDSの機能(共通)
- アーキテクチャはEC2にMySQLやPostgreSQLを自前でインストールする場合と大差ない
- レプリカを作成する場合、このインスタンス+EBS2台というセットがもう一つできる
- Aurora:インスタンスとストレージが分離している形
- リードレプリカ:読み取り専用のDBの負荷分散
- 自動バックアップ:データベースとトランザクションログ
- 自動パッチ作業
- AWS KMSの利用・連携で、RDSのインスタンスをストレージレベルで暗号化
- 機密性の高い情報にはトークン化
- マルチアベイラビリティゾーン:片方のRDSに問題が起きても影響を受けずアクセスできる
- アクセス権限:IAM機能を活用しユーザー・グループ・リソースごとにアクセス権限を設けられる
- アーキテクチャはEC2にMySQLやPostgreSQLを自前でインストールする場合と大差ない
- メリット
- https://dev.classmethod.jp/articles/developers-io-2019-in-osaka-aurora-or-rds/
- スループットが標準のMySQLの5倍、Postgresだと3倍
- バックアップ/リストア/リカバリーが早い
- MySQL / PostgreSQL 互換
- MySQLやPostgreSQLのDBエンジンからインポート/エクスポートツールやスナップショットを使用して移行が簡単にできる
- https://aws.amazon.com/jp/rds/aurora/faqs/
- デメリット
- 料金が他のDBエンジンに比べて高くなりがち
- MySQL / PostgreSQL 互換といいつつ対応できるバージョンは限定される
- 使えるインスタンスタイプが異なる
- Auroraでできない設定がある為注意が必要
- MySQLのinnodb_change_bufferingというパラメーターがAuroraでは無効
- そもそもRDSを使うべきか、選定基準について