No.
2023-08-21
  • Jan
  • Feb
  • Mar
  • Apr
  • May
  • Jun
  • Jul
  • Aug
  • Sep
  • Oct
  • Nov
  • Dec
  • Sun
  • Mon
  • Tue
  • Wed
  • Thu
  • Fri
  • Sat
  • 27
  • 28
  • 29
  • 30
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

信頼性のテスト振り返り

早引き

  • ストリーミングデータをリアルタイムで収集する -> Amazon Kinesis
  • リクエスト発生時のみ処理を発生させたい -> Lambda
  • スケーリングされるインスタンスでは、セッション情報をデータベースに保存してインスタンス間で共有するのがベストプラクティス
    • インスタンスがスケールイン(減らされる)時にセッション情報が消えてしまうため
  • 疎結合 -> SQS, Amazon API Gateway
  • RTO（Recovery Point Objective：目標復旧時点）：障害が発生した時点からどれまで前に遡るのを許容できるか
  • RTO（Recovery Time Objective：目標復旧時間)：障害が発生してからどれくらいで復旧できるか
  • スナップショットは他リージョンにリードレプリカを作るよりも安価
  • ALBのヘルスチェックだけではAutoScalingがHTTPのエラーを認識しない
    • ELBのヘルスチェックも項目に加える必要がある
  • メッセージのフィルタリング機能があるのはSNS。SQSにはない。
  • ACIDとは、原子性（Atomicity）、一貫性（Consistency）、独立性（Isolation）、耐久性（Durability）を意味する言葉で、更新処理中に中途半端なデータが書き込まれないことや、並行処理がそれぞれ独立して動作する（互いに干渉しない）ことなど、処理の信頼性を保証する性質
  • リードレプリカとは参照専用のデータベースで、パフォーマンスを向上させるしくみ。可用性にはそこまで寄与しない。可用性を求めるならマルチAZの方が良い。
  • SNSとSQSを組み合わせると「ファンアウト」構成を実装できる
    • ファンアウトとは、一つのメッセージを複数の送信先に配信し、それぞれが並列に処理を実行する仕組み

フェイルオーバー対策

サーバー構築

  • ALB配下のEC2インスタンスを停止状態にしておき、障害発生時に起動する
  • 障害発生時にAWS CloudFormationテンプレートを実行して、ALBとEC2インスタンスを作成する

前者：ダウンタイムが短い

ALBとNLBの違い

ALB

  • アプリケーション層(レイヤー7)
  • HTTP,HTTPS
  • ホストベース、パスベース、URLクエリ文字列でのルーティングが可能
  • 固定IPアドレスの割り当て不可

NLB

  • ネットワーク層(レイヤー4)
  • TCP,UDP,TLS
  • ホストベース、パスベース、URLクエリ文字列でのルーティング不可
  • 固定IPアドレスの割り当てが可能

AWS Direct ConnectとAWS Site-to-Site VPNの違い

AWS Direct Connect

  • オンプレミスなどのユーザー環境からAWSへ、専用回線を使ってセキュアに接続するサービス
  • 専用回線を敷設して使用するので、安定した高速なネットワークで接続できる
  • Direct Connectロケーション内にルーターを設置し、オンプレミスから専用線を引き込む必要がある
  • 工事費用と時間をかけてでも、安定した通信と強固なセキュリティ環境を求めるケースに最適

AWS Site-to-Site VPN

  • カスタマーゲートウェイ（オンプレミスのルーター）とVPCの仮想プライベートゲートウェイを、インターネットVPNで接続するサービス
  • インターネット回線を利用するので、専用回線を敷設するDirect Connectよりも安価に、かつ短い期間で接続を開始できる

Amazon Kinesis

  • ストリーミングデータ(継続的に生成されるデータ)をリアルタイムで収集・処理するサービス
    • 例)スマートフォンアプリなどでユーザーが生成するログや、証券取引所の株取引情報、SNSやオンラインゲームのデータなど
    • ストリーム処理　 ⇄ バッチ処理
  • サンプリングや分析などの処理を通して、リアルタイムなトレンド情報をユーザーへフィードバックしたり、企業の経営戦略などに繋げることができる
  • Kinesisではストリーミングデータを生成し送信するデバイスやサービスなどを「プロデューサー」、ストリーミングデータを読みだして処理する側を「コンシューマー」と呼ぶ

Kinesis Data Streams

  • 外部から送信されるストリーミングデータを収集
  • ストリーム上のデータは分析や機械学習などを行うアプリケーション(AWS Lambdaなど)がリアルタイムに読みだして処理
  • ストリーミングデータを「データレコード」という単位で処理する
  • データレコードには、データそのものに加えて「パーティションキー」「シーケンス番号」が含まれる
    • パーティションキー： どのシャード（後述）で処理するかを決めるもの。プロデューサー側で設定する
    • シーケンス番号： シャードごとに一意の番号。シャード内のデータレコードの順序性が保証される

Kinesis Data Firehose

  • ストリーミングデータをAmazon S3（ストレージ）、Amazon Redshift（データベース）、Amazon OpenSearch Service（データ分析）などのサービスへ配信するサービス
    • ストリーミングデータは事前に設定されたデータ配信先へ配信される。中継するアプリケーションを独自に実装する必要はない。

Kinesis Data Analytics

  • Kinesis上のストリーミングデータを処理し、可視化・分析できるサービス
    • 処理用のテンプレートが用意されていたり、標準SQLのクエリが発行できたり、JavaやPythonなどのプログラミング言語がサポートされているなど、柔軟に処理を組み込むことができる
    • データをデータベースへ移行することなく処理することで、リアルタイムに結果を得ることができる

Kinesis Video Streams

  • カメラやビデオなどの動画（ビデオストリーム）を取り込むサービス。取り込んだ動画データはアプリケーションなどによって解析や加工、再生などを行うことができる。

AWS Lambda

  • サーバーレスでプログラムのコードを実行できるサービス
    • サーバーレス：リクエスト発生時にだけプログラムが実行されるアーキテクチャ

Amazon SQS

  • フルマネージドのメッセージキューイングサービス
  • プル型のメッセージキューイングシステム
    • 受信者の都合の良いタイミングでSQSへポーリング(問い合わせ)してメッセージを受け取る
  • サービス同士の橋渡しを担う
  • ロングポーリングにすることで、APIコールがない時のコストを削減することができる
  • 可視性タイムアウトは、一度クライアントがメッセージを受信した後、指定時間（デフォルト30秒）が経過するまでそのメッセージが他のクライアントからは見えないようにする
    • SQSのメッセージを受信するクライアントが複数ある場合、タイミングによっては、メッセージが削除される前に複数のクライアントでメッセージを受信してしまうことがあるため

AWS Glue

  • データ分析向けのETLサービス
  • ETL…データのExtract（抽出）・Transform（変換）・Load（書き出し）

Amazon Elasticache

  • フルマネージド型のインメモリデータベースサービス
    • データベースの拡張や障害の検出・復旧、バックアップなどはAWSによって管理
    • インメモリデータベースはデータストレージにメモリを使用するDBのこと
    • HDDよりも高速・安定したアクセスが可能
  • RDSやRedshiftなど他のデータベースサービスと連携し、クエリの結果をElastiCacheにキャッシュさせることで全体的なパフォーマンスを向上させる、というような使い方ができる
  • ElasticacheはKVS（Key-Value Store）型のデータベースエンジンが2つ用意されており、データベースを構築する際に選択することができる
    • データベースエンジンはMemcached、Redisから選択可能

Memcached

  • 高パフォーマンスを提供する
  • データの永続保持やバックアップ機能はないため、シンプルなキャッシュとして利用する

Redis

  • 高パフォーマンス＋高可用性、機密性を提供する
  • 耐障害性の機能として「自動フェイルオーバー(障害発生時に自動切り替え)」「マルチAZ」がある
    • フェイルオーバー：プライマリノードに障害が発生した場合は自動的にレプリカノードがプライマリノードへ昇格

Route53

  • DNS名前解決サービス
  • 複数値回答ルーティングポリシーとフェイルオーバールーティングポリシーはヘルスチェックの設定が必須

フェイルオーバールーティングポリシー

  • 通常時はプライマリに設定したリソースのIPアドレスを回答、プライマリのリソースにヘルスチェックで異常が発生した場合は、セカンダリに設定したリソースのIPアドレスを回答
  • フェイルオーバールーティングポリシーをマルチリージョンで設定することで、災害時には自動的にセカンダリリージョンに切り替えられる

Amazon SNS

  • プッシュ型のメッセージングサービス
    • サブスクライバーの状況によらずメッセージの配信が行われる
  • システムの状態に変化があった際のシステム管理者への通知や不特定多数のユーザーへの定期的なメッセージ配信などができる
    • EメールやSMS、Amazon SQSを通してユーザーやアプリケーションに対して通知
  • 情報の単位は「トピック」で管理される
    • 標準とFIFO(First In First Out)の2種類がある
  • SNSトピックからメッセージの配信に失敗した場合、通常はメッセージを破棄してしまう
    • メッセージの破棄を防ぐには、配信不能メッセージをAmazon SQSのデッドレターキューに送信するようにサブスクリプションを設定する
    • デッドレターキューに保持されたメッセージをLambda関数がポーリングすることで、SNSトピックから配信された全てのメッセージがLambda関数で処理されるようになる

標準

  • 処理するメッセージの順序性が保証されない
  • メッセージの重複排除も搭載されていない
  • メッセージの配信が「少なくとも1回」される

FIFO

  • メッセージが順序付けられてAmazon SQSのFIFOキューへ配信される
  • SQS以外のプロトコルでは利用できない
  • メッセージの配信が「必ず1回だけ」される
  • イベントが発生した順番通りに処理したい場合や、処理が重複してはいけないようなケースで利用

AWS Storage Gateway

  • オンプレミスからAWSのストレージサービスへのアクセスを高速かつセキュアに行うことができるサービス
  • Storage Gatewayには3つのゲートウェイタイプがある

ファイルゲートウェイ(ファイル単位)

  • オンプレミスから、NFSまたはSMBを介してS3バケットへアクセスすることができる
    • NFS（Network File System）、SMB（Server Message Block） … どちらもサーバーなどへ保存されたファイルを複数のクライアントで共有するためのネットワークプロトコル
  • オンプレミスにキャッシュストレージを持つため、高速なデータアクセスが可能

ボリュームゲートウェイ(ボリューム単位)

  • S3をiSCSI接続のブロックストレージボリュームとして提供
  • iSCSI（Internet Small Computer System Interface）とはコンピュータのストレージを接続するSCSIプロトコルをTCP/IPで実現したもの
    • サーバーはiSCSIで接続されたストレージ（Storage Gatewayの場合はS3）をローカルディスクとして使用
  • ボリュームストレージ上のデータは任意のタイミングでS3にEBSスナップショットとして保存可能なので、災害対策や定期的なバックアップに利用可能

キャッシュ型(キャッシュボリューム)

  • キャッシュストレージをオンプレミス（ローカル）に設置することで、高速アクセスが可能な堅牢性の高いストレージを利用できる
    • オンプレミスのキャッシュストレージには頻繁にアクセスするデータのみを保持
    • アクセス頻度の低いデータはS3へ保存
    • データがキャッシュ上に存在しない場合はS3へアクセスするので遅延が発生しますが、オンプレミスのストレージ容量を抑えることができる

保管型(ストアドボリューム)

  • オンプレミスのボリュームストレージに全てのデータを保持
  • キャッシュ型とは異なり、全てのデータに対して高速アクセスが可能
  • ボリュームストレージ上のデータは任意のタイミングでS3にスナップショットとして保存され、災害対策や定期的なバックアップとして利用できる

テープゲートウェイ(仮想テープ単位)

  • 最も価格が安いので、長期保存やアーカイブなどに最適

AWS Global Accelerator

  • ユーザーからAWSリソースまでのアクセス経路をAWSネットワークを利用して最適化するサービス
  • オンプレミスには利用不可

Amazon RDS

  • フルマネージド型のリレーショナルデータベース
    • フルマネージド：データベースのスケーリング（拡張、縮小）、ストレージの拡張、高可用性、バックアップ、OS/データベースソフトウェアへのパッチ、サーバーの電源やメンテナンスなどが管理された状態
  • RDSにおける自動バックアップの保持期間は最大で35日・自動バックアップ頻度は最短1日まで
  • これを超えて保存したい場合は次のようにする：
    • AWS Backupでバックアッププランを作成する
    • 手動でスナップショットを取得する(手動で取得したスナップショットには保持期間の上限なし)
    • 自動バックアップで取得したスナップショットをS3バケットへ手動でコピー（エクスポート）する

Amazon Aurora

RDSで利用可能なデータベースエンジンの一つ

  • 他のデータベースエンジンと違う点：
    • データベースインスタンスとストレージが分離したアーキテクチャ
    • 複数のデータコピーと自動修復機能などによるストレージの高い耐障害性
    • レプリカインスタンスの自動フェイルオーバーによる高可用性
    • 最大64TBまでスケール可能な拡張性
    • Aurora Auto Scalingによる負荷の自動調整
    • データベースのクローンを高速作成

AWS Backup

  • ストレージやデータベース等のバックアップを一元管理するフルマネージドのサービス
  • EC2インスタンスやEBSボリューム、S3バケット、RDSなどを対象に、柔軟なバックアッププランを作成できる
    • バックアップの頻度や、一定期間を経過したバックアップはコールドストレージへ保存する、別のリージョンへ保存するなどの運用も可能
    • RedShift, Elasticacheは対象外