インフラ / バックエンド担当の森井です。
今年の11/28から12/2にかけて行われるre:Invent 2022に現地参加しています。
今まで動画でしか見てこなかった憧れのイベントなので、とてもワクワクしています！ せっかくなので参加したセッションの内容を振り返って行きたいと思います。
初日の個人的深堀りテーマはズバリ、「パフォーマンス」です。 パフォーマンスを向上させれば、利便性でだけでなくコスト削減にもメリットがある場合も多く、様々な面で良い影響を引き起こすことができます。
この記事では、1日目に参加したセッションで特に面白かった2つを紹介します。 どのセッションも後々YouTube等にアーカイブが公開されると思うので内容を詳しくは書くことはしませんが、概要と個人的に学びになったことを書いていきます。
ちなみにこの投稿は Fenrir Engineers 初投稿です。 書きたい書きたいと思いつつ、先延ばしにして今に至るので、これを機に習慣化していきたい所存です。
Optimize price and performance with Amazon EBS
記念すべき最初のセッションです。 みなさんはEBSのボリュームタイプを選ぶとき、どのようなことを考えるでしょうか。 とりあえず何も考えずに8GB gp2（コンソールから作成するときのデフォルト）を当てておくことも多いと思います。
かく言う私も正確な選び方がわからなかったので、このセッションに参加しました。 このセッションでは、近年のEBSの進化の説明から始まり、アプリケーションの種別ごとに最適なボリュームタイプの選び方を知ることができました。
現在は主に gp3（汎用SSD）、io2（Provisioned IOPS SSD）、st1（スループット最適化 HDD ）、s1（Cold HDD）の中から選ぶことになります。 どのボリュームタイプが適切か検討する際、考慮するべきは下記の項目だそうです。
- ミッションクリティカルなワークロードか？
- どのレベルのパフォーマンスを求めるか？
- データベースはレプリケーションを内蔵しているか？
- レイテンシの要求はどの程度か？
- どのタイプのEC2インスタンスを採用しているか？
セッションの中での具体例を踏まえると、下記の観点が重要なようです。 ワークロードが下記の点で何を求めるのかに回答できれば、自ずと最適なボリュームタイプを決めることができますね。
- ランダムI/OかシーケンシャルI/Oか
- レイテンシはどの程度許容できるか
- スループットはどの程度必要か
- コスト効率が重要か
※「データベースはレプリケーションを内蔵しているか？」については英語力が足らず、意図がよくわかりませんでした。
Amazon EBS ボリュームの種類にも詳しく記載されていますので、是非ご覧ください。
また、コンテナワークロード用としてAmazon EBS CSI Driver も紹介されていました。今後EKSを使用する際には検討してみようと思います。
違いを意識した上で、意図したパフォーマンスを実現できるようにボリュームタイプを選んでいきたいですね。
Nasdaq: Moving mission-critical, low-latency workloads to AWS
AWSをフル活用して電子証券取引を実現するNasdaq社の発表でした。 超低レイテンシが求められるマッチングエンジンシステムをついにAWSに移行したそうです。このことは2日目の Adam Selipsky Keynote でも記念すべきこととして触れられていました。
超低レイテンシということで、マッチングエンジン部分はOutpost を採用しています。 Outpostは個人的に気になっているものの、気軽に試せるものではないため事例が聞けたのは良かったです。
面白かったのはパブリッククラウド上で行うような（あるいは隠蔽されている）冗長化を、Outpostでも実現できるということです。
これを自前で組むのが容易でないことは想像に易いので、このあたりも Outpost を使ってオンプレミス環境を作るメリットになるわけですね。 つまりOutpostを採用することで、AWSの多様な機能を活用しつつ、超低レイテンシが実現できると。 Outpostのコストを許容できるプロジェクトは多くないと思いますが、設計のパターンとして引き出しに入れておくと良いと思いました。
明日以降も何かネタを見つけてブログにしていきたいと思います。お楽しみに。
