dely Tech Blog

クラシル・TRILLを運営するdely株式会社の開発ブログです

AWS Summit Japan 2024 参加レポート

こんにちは、クラシルリワードでSREエンジニアをしているkatotakです。 6/20・21に幕張メッセで開催されたAWS Summit Japan 2024に参加してきました！

aws.amazon.com

今回は業務の時間を使ってイベントに参加することができたので弊社メンバー数人とDay1・Day2に分かれて参加しました！ (delyでは必要に応じて平日開催されるイベントへの参加もできます！)

参加の目的・モチベーションとして、弊社ではクラシルリワードだけでなくクラシルやその他のサービスにおいてAWSを主要なクラウドサービスとして活用してサービスを提供しています。 そこで普段利用しているサービスへの知見を深めることや昨今注目されている生成AI関連のサービスなどトレンドを追いかける機会を設けて開発者自身のスキルアップや今後の開発に活かしていくことを目的・モチベーションとしています。

個人的に今回参加して普段利用しているサービスの内部のアーキテクチャにDeep diveしたり、まだ利用したことがないサービスの使い所について知見を深められたことで普段の開発へのモチベーションやアーキテクチャを考えることが楽しみになりました！

セッション

ここからは参加したセッションについての内容や参加メンバーの感想を書いていきます！

Day1

インシデント対応を 10 倍速くする方法、教えます - PagerDuty と AWS で爆速障害対応

資料はこちら

このセッションでは、サービス運用をする上では目を逸らすことのできない「インシデント」において、より早く気づき、より早く直すために重要な観点を紹介されました。

◇ PagerDuty

インシデント対応においては

  • 検知
  • 影響範囲の把握
  • ステークホルダーとのコミュニケーション
  • 様々な調査や復旧における作業

など、様々な作業を行う必要がありますが、それをサポートしてくれるPagerDutyの紹介がありました。

インシデントにより早く気づくことを目的として、データの収集や膨大なデータの中からインシデントを検知し、然るべき通知を行う仕組み

インシデント対応に必要な、コミュニケーションの場の自動提供、対応ステータスの可視化

◇ インシデントコマンダーの重要性

そして、セッションを通じてお話しされていたのは、インシデントコマンダーの重要性でした。

インシデント対応においては前述の通り、様々な作業を複数の人がそれぞれの役割を持って対応することが必要となってきます、そんな状況の中、インシデント解決のために「全体の交通整理」「意思決定」を行うことがインシデントコマンダーの役割と紹介されています。

◇ インシデントコマンダーになれる人

インシデントコマンダーは特別な技術や知識必要が必要なのではなく、下記の点が重要であると紹介されていました。

◇ よぎった考え

このセッションを拝聴する前にAWSのブースにおいて障害対応におけるLLM利用のサンプルを拝見していたため、インシデントコマンダーの役割を一部でもLLMで担うことはできないかと想像しました。

資料はこちら

特に前述のインシデントコマンダーになれる人の

  • サービスがどのように連携しているかの理解
  • 状況を判断して、行動方針に対する迅速な意思決定ができる

上記の点について特にサービスに長く携わっていることが必要となり属人性が発生してしまうこと、インシデントが頻繁に発生しないためインシデントコマンダーの経験を積む機会が少ないことが課題です。その結果、いざという時の意思決定が難しく何から交通整理をすべきかの判断に迷ってしまうことが多い印象があります。

そこで、LLMにおいて状況の把握をすることができれば、意思決定や交通整理のサポートの役割を担うことができるのではと感じました。

ただし、企業やサービスによって同じ状況でも意思決定の方向性が異なるので、LLMをサービスに特化させる必要があるので、道のりは遠いですが、今からその未来に向けてアウトプットを整理することから始めていこうかなと思いました。

Day2

AWS NoSQL コスト削減大全

資料はこちら

データベースのコスト削減と聞くと、「高い可用性が求められ、専門性が高く、とにかく難しい領域」というイメージを持たれている方は多いのではないでしょうか？

かく言う私も、そのように捉えていました。

このセッションでは、データベースにおけるコスト削減は通常のデータベースよりも比較的簡単だと紹介されており、具体的なコスト削減のためのアクションに繋がる考えや知見を得ることができました。

本トピックでは、まずNoSQLデータべースのコスト削減についての大枠から入り、具体的なデータベースサービスでは、弊社のサービスにも大きく関わってくるAmazon DynamoDBを中心に、コストの構造と効果的なコスト削減方法について、セッションの内容をもとにした学びと感想を共有します。

◇ コストとは？

まず、プロダクトにおけるコストとは、以下のような要素に分解することができると紹介されています。

  • インフラコスト：サーバーやストレージの使用に伴うコスト
  • ライセンスコスト：商用サービスなどの使用料
  • オペレーションコスト：メンテナンスや人材の時間的コスト
  • 開発コスト：開発のしやすさに関わるコスト
  • ビジネスコスト：メンテナンスや障害による機会損失

◇ データベースのコスト削減の難しさ

先にも紹介した通り、「データベースのコスト削減＝難しい領域」という先入観にとらわれがちです。しかし、ことNoSQLデータベースにおけるコスト削減は通常のデータベースよりも比較的簡単だと紹介されていました。

AWSのデータベースサービスはPurpose-built Databaseという目的別に特化されたデータベースが複数用意されています。

なので、「目的に沿って適切に使用することでベストプラクティスになりやすく、このベストプラクティスに従うことで自然とコストが最適化される」という点が通常のデータべースと違って扱いやすい点だと言えます。

◇ コスト削減のポイントは

NoSQLデータベースのコスト削減ポイントは以下だと紹介されています。

  • サイジング：適切なコンピューティングリソースの選定
  • スケジューリング：リソースの適切なタイミングでの割り当て
  • 価格体系：適切な価格モードの選定
  • データモデリング：効果的なデータモデリング

◇ DynamoDBにおけるコスト削減のポイント

では、上記のポイントを踏まえて、具体的にDynamoDBにおいてはどのようなコスト削減のベストプラクティスがあるのかについてセッションで紹介された内容を一言でまとめると、「価格体系の選定とキャパシティユニットの理解」と結論づけました。

前提としてサーバーレスなDynamoDBには「プロビジョンドキャパシティ」と「オンデマンドキャパシティ」という二つの価格体系があります。そしてこれらがキャパシティユニットという単位で計測されています。

◇ 価格体系の選定

「プロビジョンドキャパシティ」と「オンデマンドキャパシティ」のどちらを選ぶことが最適なのかについては、二つのモードをフルで使って均一なスループットが来た時の比較をイメージするのが手っ取り早いです。

もしプロビジョンドモードである程度の値でピークを設定した時に、実際の使用率が14.4%だった場合、「プロビジョンドモード」の方が7倍もコストが安くなります。

安全率は大体50%(スパイクしやすいものならもう少し上)なので、プロビジョンドモードで設定して安全率50%なら、オンデマンドモードでたまに来るスパイクを処理しているよりもコストは低くすることができます。

また、プロビジョンドモードはリザーブドキャパシティが使えるため、計算上約3.2%の使用率でもプロビジョンドモードの効率が良いとされています。

では、オンデマンドモードどのような時に最適な選択肢とされるのかについては、

  • オートスケーリングの設定やピーク時の処理やスロットリングエラーをどうしても出したくない。

  • その瞬間のオペレーションコストやビジネスコストを減らしたい

といった時に有効とされています。

「プロビジョンドモード」と「オンデマンドモード」は切り替えが可能なので、現状の波形やビジネス的な観点から切り替えることも有効言えます。

◇ キャパシティユニットの理解

キャパシティユニットは読み込み時と書き込み時でコストが異なり、読み込みは書き込みの5倍安い設定になっています。「1WCU=5〜40RCU」

この読み込みと書き込みのコスト差分を意識した設計を行うことで、全体コストを大きく下げることが可能と言えます。

例えば、indexを作る時に発生する書き込みにおいて、もしindexを作らず5回未満の読み込みと、絞り込みによってデータが取得可能であるのならば、セカンダリインデックスを作るよりもコストを抑えることができるなど。

感想

今回のセッションで、データベースのコスト削減は一度の対策で終わるものではなく、継続的な見直しと改善が必要であることを学びました。特に、DynamoDBのようなNoSQLデータベースでは、適切な価格体系の選定や効果的なデータモデリングがコスト削減の鍵となります。

また、コスト削減の取り組みはビジネスの直接的な利益に繋がるため、組織全体での取り組みが重要です。今後もコスト削減に向けた最適化を続けていくことで、より効果的なシステム運用を目指していきたいと思います。

Amazon Aurora の技術とイノベーションDeep dive

資料はこちら

このセッションではAmazon Auroraのアーキテクチャ・グローバルデータベースの説明から始まり、Serverless v2やBlue/Greenデプロイ・Zero ETLなど運用上で役立つ機能やストレージタイプ・pgvectorなどの新機能の紹介が行われました。

アーキテクチャ

Auroraストレージは3AZに分散して配置されることで可用性や耐久性を担保していることや コンピュートとストレージが分離されているアーキテクチャであるため、リードレプリカの追加がストレージのアタッチのみだけで完結する点がアニメーションで説明されわかりやすかったです。

管理性 – Aurora Serverless

Amazon Aurora Serverless v2の使いどころについてあるワークロードをもとにプロビジョンされたインスタンスとServerlessで比較を行いCPU・メモリがスケールアウトされることによるレイテンシーへ効果が説明されました。

Serverlessを使用することでワークロードの負荷に合わせて自動でCPU・メモリをスケールすることができるので一定時間に集中して使用負荷が高まるような場合には非常に有効な手段になることがわかりました。クラシルリワードにおいても日次で一時的に多くのデータを取得するようなワークロードがあり、Serverlessインスタンスを使用することで適切なリソースで処理を実行できパフォーマンスの維持・向上が見込めそうだなと思いました。

docs.aws.amazon.com

新しい Aurora ストレージ タイプ

新しいAuroraストレージタイプとしてAmazon Aurora I/O-Optimizedが紹介されました。 I/O-Optimizedではコンピューティングとストレージコストがスタンダードと比較して増加しますがI/Oが多く発生するようなワークロードにおいては最大40%減のコストパフォーマンスが発揮できたりパフォーマンスの向上が見込めます。

実際にクラシルリワードでのI/O支出についてCost Explorerで確認をしてみましたが現状では支出に占めるI/Oの割合は高くない状態であったため、今後のコストを確認する中で最適化できそうなタイミングで導入を検討したいと思います。

Amazon Aurora Limitless Database 内部アーキテクチャ詳解 〜 スケーラビリティと高可用性の秘密 〜

資料はこちら

このセッションではAmazon Aurora Limitless Databaseについての開発背景や内部アーキテクチャ・開発にあたり大事にしていることが紹介されました。 AWS re:Invent 2023にてAmazon Aurora Limitless Databaseが発表されたことは知っていましたが内部のアーキテクチャについてかなり踏み込んで説明されておりボリューミーなセッションでした。

Amazon Aurora Limitless Databaseとは

現在Limited Preview中でPostgreSQLエンジンでのみ提供されているマネージドなシャーディングサービスです。 開発背景としては事業を運用していく中で扱うデータサイズが増えたり、機能追加やイベント時のスパイク等によってライターのスケーラビリティが要求される場合にデータをシャーディング（水平分割）を行いテーブルを複数のチャンクに分割して保存するのが一般的です。 ですが、トレードオフとしてデータがどのシャードにあるかや複数のシャード内のデータの結合やトランザクションの一貫性の担保やデータのバックアップをどうするかなどメンテナンスコストが上がってしまいます。これらのシャーディングにおける問題を解決することを目指して作られたものがAmazon Aurora Limitless Databaseです。

Amazon Aurora Limitless Databaseは1つのエンドポイントに繋いで使うだけでよくアプリケーション上での接続切り替え処理が不要で1 秒あたり数百万件を超える書き込みトランザクションにスケーリングしペタバイト単位のストレージを管理可能することができるそうです。分散トランザクション・クエリについてもサポートされます。

Shard management

  • Sharded table

シャーディングが行われるテーブルで各シャードにデータが配置される。 シングルシャードでクエリ実行されるとパフォーマンスが良いので関連するレコード(ex. user_id)などは同じシャード内に配置することをコロケーションと読んでいる

  • Reference table

更新量が少なくデータサイズが小さいテーブルのことで、Reference tableは各シャードへ配置を行いできる限りシングルシャードクエリで実行できるように自動で配置される

シャーディング対象にしたいテーブルを作りたい場合はセッション変数でテーブル対応を指定することでテーブル作成ができるのでセッション変数を使わなければローカルやCI/CDの際のテーブル作成も容易になる設計にしているとのことです。

Internal Architecture

Auroraクラスタ内にシャードグループというものが作成されてその中に必要機能が内包されており単一のエンドポイントが提供され、指定しているキャパシティで自動でスケーリングを行う。

  • Distributed transaction routers

エンドポイントを提供してどのシャードにどのデータがあるかのメタデータを管理、時間ベースのトランザクションで使用するための時間払い出し・クエリの実行プラン解析・分散トランザクションやクエリの場合は集計等を行うレイヤー

  • Data access shards

メタデータだけを保持している。 ルータから時間情報とクエリの実行計画を受け取りクエリを実行してルータに結果を返すレイヤー。シングルシャードトランザクションである場合はこのレイヤーでコミット・ロールバックを行う。 シングルシャードのクエリをうまく使うと並列化できるのでスループットが良くなる。

Challenges in a distributed database

分離レベルを守るためにBounded clocksという仕組みを使ってクエリの整合性や実行順序を保証している。

  • Current time

  • Earliest possible time

  • Latest possible time

EC2 TimeSync serviceから時刻情報の信頼区間を配信して使用することでPostgreSQLの分離レベルを守るために連携している。実際にどのようなフローでトランザクションが実行されるか資料では説明されています。

1つのエンドポイントに繋いで普段通りのクエリを実行するだけで書き込みのスケーリングや分散トランザクション・クエリを裏側で良しなにやってくれるのは開発者側からすると事業ドメインの開発により時間を使えるので嬉しいですね！ 使いどころとしては書き込み性能を上げたい・MySQL/PostgreSQLインターフェイスを使いたい・分散トランザクションやクエリをマネージドに処理したい場合に有用とのことでした。

アーキテクチャ道場！

アーキテクチャ道場は、AWSのSAが実際に設計したアーキテクチャを題材に、チーフテクノロジストがレビューを行う実践的なセッションです。今回はレジリエンス向上をテーマに2つのケースが用意されていました。

ケース1：クレジットカード会社のシステム

一つ目のお題はクレジットカードの決済システムに関するものでした。A社は全てのシステムをAWS上で運用しており、特に決済関連のアプリケーションは高い可用性が求められるため、以下の対策を講じていました

  1. 全てのリソースを複数のAZに冗長化
  2. セカンダリーリージョンへのデータレプリケーション

この構成は完全な障害（バイナリー障害）やブラックアウトには有効でしたが、グレー障害やブラウンアウトには十分に対応できていませんでした。

  • グレー障害：観測される状態が視点によって変化する障害。例えば、インフラの死活監視は成功するがアプリケーションが正常に応答しない状態。
  • ブラウンアウト：機能は完全には失われていないが品質が低下している状態。例えば、パフォーマンスが徐々に悪化したり、エラーレートが上昇したりする状態。

(グレー障害、ブラウンアウトという単語はこのセッションで初めて名前がついていることを知りました...!)

改善の方針

セッションでは、以下の2つの主要な方針が示されました

  1. 障害のあるAZを検知し、ワークロードから切り離す

    • 検知：グレー障害・ブラウンアウトを考慮した障害検知
    • 隔離：障害のあるAZへのリクエスト流入を遮断

  2. AZ間の独立性を高める

    • AZを跨ぐ通信・処理をアーキテクチャから極力排除

具体的な改善策

これらの方針に基づき、以下の具体的な改善策が示されました：

  1. Application Load Balancer（ALB）の設定変更

    • クロスゾーン負荷分散をオフにし、LBからフロントサービス間の通信がAZを跨がないようにする

  2. Amazon EKSの構成変更

    • Fargate profileを各AZに個別に作成
    • 各AZごとにDeploymentを作成し、各AZに確実にPodが存在するようにする

  3. フロントサービスからバックサービスへの通信改善

    • バックサービスをAZごとに作成
    • 各AZのフロントサービスからのエンドポイントを環境変数に個別に指定

  4. データベース層（Amazon Aurora）の改善

    • 各AZのインスタンスを指すカスタムエンドポイントを作成
    • 各AZのバックサービスからのDBエンドポイントとして指定
    • ただし、更新系クエリについてはAZを跨ぐ通信を許容（プライマリーインスタンスは1つのみのため）

障害検知の方法

障害を正確に検知し、不要な隔離を避けるために、CloudWatchで以下の複合的な条件を設定していました

  1. AZ-1へのリクエスト全体でエラー率・レイテンシが増加
  2. AZ-1からプライマリーDBへのアクセスでエラー率・レイテンシが増加
  3. 上記の現象がリージョン全体の障害ではないこと
  4. 上記の現象がDBプライマリーインスタンスの障害ではないこと

これらの条件を監視するために、以下の実装が示されました：

  • ALBのCloudWatchメトリクスをAZ単位でアラーム化
  • 各AZからプライマリーDBへのヘルスチェックを実装（Amazon CloudWatch Syntheticsを利用）
  • 上記のアラームを組み合わせた複合アラームの作成

障害検知後の対応

障害を検知した際の隔離方法として、Amazon Route 53 Application Recovery Controllerを使用することによって、障害が検知されたAZへのトラフィック流入をデータプレーンレベルで制御することが可能になります。

ケース2：外部サービス依存のあるシステム

お題2では、ECサイトを運営するB社が依存するサードパーティのサービスの障害への対処方法が検討されました。

このサードパーティサービスは信頼性が非常に低く、リクエストが集中するとすぐにエラーレスポンスの返却やパフォーマンスの悪化が始まります。現在のアーキテクチャでは、サードパーティサービスに問題が発生するとアプリケーション全体にその影響が広がってしまうため、B社はサードパーティサービスとアプリケーションの依存関係を緩和することで解決を図ろうとしていました。

この問題に対する解決策として、プロキシサービスの導入が示されました。

プロキシサービスは、アプリケーションとサードパーティサービスの間に位置し、以下の主要な機能を提供します：

  1. 負荷の緩和

    • レートリミット
    • キャッシュ

  2. 障害影響の遮断

    • サーキットブレーカー
    • バックオフリトライ
    • 非同期処理

プロキシサービスは、サードパーティサービスの処理要件に応じて、以下の4つのアクセス方式を提供します：

アプリケーションは、リクエスト時にこれらのアクセス方式を選択します。

プロキシサービスの主要コンポーネントとその役割は以下の通りです：

  • リクエストハンドラー：アプリケーションからのリクエストを受け付け、適切な処理を行う
  • レートリミット：サードパーティサービスへのリクエスト数を制限する
  • サーキットブレーカー：サードパーティサービスの障害を検知し、一時的にリクエストを遮断する
  • バックオフリトライ：エラー時に一定の間隔を空けて再試行する
  • キャッシュ：読み込みリクエストの結果をキャッシュし、サードパーティサービスへのアクセスを減らす
  • 処理キューとコンシューマー：非同期処理のためのキューとその処理を行うコンポーネント
  • ステートウォッチャー：非同期処理の状態を監視する

これらのコンポーネントにより、サードパーティサービスの障害や負荷増大時にも、アプリケーションへの影響を最小限に抑えることができます。

このアーキテクチャにより、B社はサードパーティサービスの信頼性の低さやパフォーマンスの問題から自社のアプリケーションを保護し、より安定したサービスを提供できるようになります。

さいごに

AWS Summitへの参加を通じて普段とは別の視点から現在のアーキテクチャを考える機会になりクラシルリワードでどのように活かせるかを考えるいい機会になりました！
今後もこのような機会を活かしてスキルアップを図りサービス成長に貢献していきたいと思います！

delyではサーバサイドエンジニアを大募集しています！
フルサイクルエンジニアリングを推進していてサーバサイドエンジニアもAWSサービスを使ってプロダクト開発・運用などを行うシーンが多くあります！

気になる方はぜひカジュアル面談でお話しましょう！！！

herp.careers

その他のポジションも大募集中です！

dely.jp