安定した性能を実現するEBS構成アーキテクチャ紹介セッションはじめにいつも単純に使っているEBSについて、性能的な向上について悩んで本セッションを参加し、一貫した性能のためのEBS構成アーキテクチャについて理解を深める時間になることを望み参加しました。EBSで複数のワークロードに対応し、I/O集約的でミッションクリティカルなデプロイメントを実行するための参照アーキテクチャと新しい拡張機能について説明するセッションです。パフォーマンスに影響を与える要素として、ストレージのパフォーマンスはシステム全体のパフォーマンスの一部に過ぎません。各スライドの説明ファイルシステムは図書館のインデックスカタログに例えることができます。カタログは正確な位置を教えてくれます。その位置を知れば、グループの位置へ行って正確な位置に行くことができ、必要なものを見つけることができます。パフォーマンスを最適化するための最適なファイルシステムを選択するにあたり、並列ファイルシステム、同時転送IO数、ファイルのサイズなどを考慮する必要があります。一般的にLinuxカーネルでEXT4はCPU使用量が少なく、小さなファイルに適していますが、データベースを扱う場合はXFSがより良い選択である可能性があります。EBSは分散型ネットワークに接続されたブロックストアをEC2インスタンスに提供するサービスです。分散サービスとして高性能と高可用性を提供するように設計されており、EBSボリュームを使用してインスタンスを起動すると、そのインスタンスのブートデバイスもEBSスナップショットから生成されたEBSボリュームから作成されます。EBSボリュームはEC2インスタンスとは別のライフサイクルを持っていることも重要な事実です。EBSボリュームタイプは、ほとんどのワークロードに対して最高のパフォーマンスを提供し、必要に応じてパフォーマンスを向上させることができます。Latency、IOPS、Throughputに対して提供される性能は、EBSボリュームタイプによって異なります。Cloudwatchでパフォーマンス指標で考慮すべき主要なVolumeWrite/Readメトリックを通じ、EBSのパフォーマンスをモニタリングすることができます。HealthをチェックできるCloudwatchメトリックも追加されました。Checkセッションを終えてEBSはシステム全体のパフォーマンスの一部であることを確認できる時間であり、パフォーマンス要件に応じてEBSボリュームとEC2インスタンスを選択するためにワークロードをモニタリングし、ベンチマークして設定を変更する必要があるかどうかを判断できるようにしなければならないという基本的なことですが、改めてリマインドすることができるセッションでした。