はじめに こんにちは！新卒一年目の関澤と福井です。 技術研修の一環として、AWS JumpStart 2026に参加してきました！この記事では、2日間のプログラム内容と、グループワークで設計したECサイトのアーキテクチャ、参加した感想を紹介します。 参加目的 参加前は、EC2やRDS、S3といったAWSサービスの名前や役割は知っていても、それらを実際のシステム要件に合わせてどう組み合わせればよいのかまでは、具体的にイメージできていませんでした。可用性・スケーラビリティ・セキュリティといった非機能要件を、どのようにアーキテクチャへ落とし込むのかを学びたいと考えていました。 AWSのサービスを個別に覚えることではなく、「どのような要件に対して、なぜその構成を選ぶのか」という判断基準を身につけるために、本イベントに参加しました。 AWS JumpStartとは AWS初学者のエンジニアを対象とした実践的な研修プログラムです。事前学習と2日間の集中的なオンラインワークショップを通じて、AWSへの理解を深めます。単なるサービスの学習にとどまらず、要件に合わせてアーキテクチャを検討・設計するところまで行います。 本プログラムのゴール 一般的なリファレンスアーキテクチャの理解 AWSのコアサービスの概要とその選定基準の理解 AWSのアーキテクチャ図を作成するまでの流れを知る 実施日時 2026年6月4日（木）〜 6月5日（金）の2日間 使用ツール Discord / Zoom / Miro / ハンズオン用AWSアカウント スケジュール   1日目 1日目は、フェーズに応じたアーキテクチャ設計の講義と、Webアプリケーションを構築するハンズオンを行いました。 午前 講義：1人から1000万人までのアーキテクティング AWSソリューションアーキテクトの方より、Webアプリケーションをスケール（拡大）させていく際のアーキテクチャ設計について講義していただきました。サービスの利用ユーザーが数十人規模のプロトタイプから1000万人規模の大規模システムまで、フェーズや目的によって目指すべき構成が全く異なることを確認しました。 講義では以下のような利用ユーザー数に合わせたフェーズごと設計のポイントを学びました。 プロトタイプ期（- 100人） ：限られたユーザーの利用が想定されるフェーズです。Amazon EC2 + Amazon RDS + Amazon Route 53のようなシンプルで安価な構成になります。この時点では、可用性・拡張性は考慮しません。 成長期（- 10,000人） ：サービスを一般向けに公開するフェーズです（午後のハンズオンで扱う）。「障害は起きるものと考え、起きても止まらないように設計する」という Design for Failure の思想に基づき、単一障害点を排除します。具体的には、Webサーバーとデータベースを分離し、ALBで負荷分散しながら複数のAZに冗長化します。 拡大期（- 1,000,000人） ：多数のユーザーが快適に利用できるように改善するフェーズです。Auto Scalingによるコスト最適化、Amazon ElastiCacheによるキャッシュ、計測・分析・改善のサイクルなどを導入します。 成熟期（それ以上） ：さらに意識して計測・分析・改善のサイクルを回すフェーズです。可用性や拡張性が強く求められるのはもちろんのこと、組織や運用もスケールする設計が求められます。非同期処理化や、NoSQLの利用、運用オペレーションの自動化などの改善をし続ける必要があります。 午後 ナビゲータとドライバーに分かれて以下の構成を目指し、コンソール上でのハンズオンに取り組みました。 単に手順通りにリソースを作成するだけでなく、AWSコンソール上での操作に慣れることと、それぞれのサービスがなぜこの構成に含まれているのかを理解することを意識しました。 1. ALB(Application Load Balancer) インターネットからのリクエストを受け取り、複数のアプリケーション実行環境へ分散する役割を持ちます。 単一のサーバーに依存せず、障害時にも正常な環境へ通信を流すための構成であることを理解しました。 2. ECS + Fargate（Amazon ECS on Fargate） アプリケーションをコンテナとして実行する環境です。 サーバー自体の管理を意識しすぎずに、アプリケーションを動かす仕組みを構築できる点を学びました。 3. RDS（Relational Database Service） アプリケーションのデータを管理するデータベースとして利用しました。 アプリケーション層とデータベース層を分けることで、それぞれを独立して管理・拡張しやすくなることを理解しました。   2日目 アーキテクティング 1日目に学習した内容を振り返るためのクイズワークショップから始まり、提示されたシステム概要からAWS構成図を作成するアーキテクチャ検討ワークショップに取り組みました。 クイズワークショップではAWSコアサービスの特徴を理解できただけでなく、 ”想定しているユースケースごとにアーキテクチャの最適解が変わる、複数存在する” という重要な知見を得ることが出来ました。丁寧に解説をしていただいたおかげで回答として提示されたものがより適している理由、自分の回答が最適となるユースケースを理解することができました。 アーキテクチャ検討ワークショップではクイズワークショップで理解した”ユースケースごとにアーキテクチャの最適解は変わる”ことを意識して取り組みました。言い換えればアーキテクチャを考えるにはユースケース、機能要件・非機能要件を具体的に想定することから始める必要がありました。 午前中は個人でアーキテクチャを検討し、午後はチームメンバー(各チーム5人ほど)ですり合わせて一つの構成図を作成しました。 福井チーム 想定するユースケース・要件 対象: 国内ユーザー 負荷特性: 多数の同時アクセスに耐えうるトラフィック制御とオートスケーリング 構成要素: 商品画像等の静的ファイルを大量に配信 決済・配送・在庫管理は外部サービスと連携 工夫した点 1. 高可用性・冗長性の確保 マルチAZの構成 VPC内に2つのAvailability Zone（AZ）を設け、Web/App層（Amazon ECS/Fargate）およびDB層（Amazon Aurora）を双方に分散配置することで、単一障害点を排除し、高い可用性と耐障害性を実現しています。 データベースの読み書き分離と可用性向上 Amazon Auroraを採用し、片方のAZにWriter（書き込み）、もう片方のAZにReader（読み込み）を配置しています。 データのレプリケーションによる冗長性を確保するとともに、読み込み処理を分散してデータベース全体の負荷を軽減・高速化しています。 2. パフォーマンス最適化と負荷分散 CloudFront × S3 によるキャッシュ・静的コンテンツの配信最適化 静的コンテンツは Amazon S3 に格納し、前段に Amazon CloudFront を配置することで高速配信を実現すると同時に、オリジンサーバーへの直接的な負荷を大幅に削減しています。 ALBによるアクセス分散 Application Load Balancer (ALB) を導入し、各AZに展開された Amazon ECS (Fargate) タスクへトラフィックを均等に分散。突発的なアクセス増加にも耐えうる構成としています。 3. セキュリティと認証の強化 エッジセキュリティ（AWS WAF） CloudFrontの前段に AWS WAF を設置し、Webアプリケーションへの不正アクセスや悪意ある攻撃（SQLインジェクションやXSS等）を最前線で防御します。 認証基盤の統合（Amazon Cognito） ユーザーの認証・認可処理を Amazon Cognito に委任することで、安全かつスケーラブルなユーザー管理を実現しています。 ネットワーク分離（Public / Private Subnet） コンテナ（ECS）やデータベース（Aurora）などの主要リソースはすべてプライベートサブネット内に配置。インターネットからの直接アクセスを遮断し、NAT Gateway 経由で必要な外部通信のみを許可する堅牢な構成にしています。 改善点 現場・実運用における問題意識 実際の障害ではAZが完全に停止するよりも「不安定に繋がり続ける状態（部分障害）」が発生しやすく、ALBでは2AZ構成の際に手動で切り離すことが不可能であるため、2AZ構成では障害AZにアクセスの半数が流れ続けてしまうリスクがある。3AZ構成にすることで手動での切り離しを可能にすると同時に影響を1/3に抑え、より堅牢な耐障害性を確保するようにすべき。 ログ取得・監視基盤の拡充 アクセスログやアプリログを取得・集約し、運用監視や監査ができる仕組みを導入する。 セキュリティ対策の高度化 脆弱性診断の導入や脅威検知など、セキュリティリスクへの継続的な対策の組み込み。 関澤チーム 想定するユースケース・要件 私たちのチームは「ユニコーン（本物）を売るECサイト」という空想的な設定で検討を進めました。アイデアを出してくれたのは、企画が得意な非エンジニアの方で、こういう突飛な設定でアーキテクチャを設計できるのはJumpStartならではでした。 最終的には、このテーマに「特定時間にアクセスが集中するECサイトを構築する」「顧客アカウントのセキュリティを厳重にする」といった各メンバーの要件をまとめて、可用性、セキュリティ、運用面などを重視したアーキテクチャを設計しました。 どう設計したか 設計した構成は、ユーザーのリクエストが上から下へ絞り込まれていく形です。リクエストの経路を辿りながら各構成要素の役割を紹介します。 Amazon CloudFront + AWS WAF ユーザーのリクエストが最初に到達するのは CloudFront です。ここに WAF をアタッチし、明らかに不正なリクエストを入口で遮断します。当初は WAF をどこに置くべきか迷ったのですが、攻撃をできるだけ手前で落とすほど後段への負荷が減ると整理できました。 WAF を通過したリクエストのうち、商品画像などの静的ファイルは、アプリケーションに届く前に CloudFront のキャッシュ、あるいは Amazon S3 から直接返します。静的なデータとアプリサーバーを切り分けることで、配信をエッジに寄せてオリジンの負荷を大きく削減できると気づきました。 Application Load Balancer（ALB）+ AWS Fargate（ECS on Fargate） 動的な処理は ALB を経由し、2つのAvailability Zoneに配置した Fargate のタスクへ振り分けられます。Fargateを選んだのは、サーバー自体の管理を抱え込まずに済み、アクセス増加に合わせて台数を伸ばしやすいためです。またALBについては、単なる負荷分散としてではなく「AZ障害が起きたときトラフィックをどう逃がすか」を考える起点として捉えるようになり、1日目に学んだDesign for Failureを自分たちの構成に落とし込めた実感がありました。 データベース ECサイトのデータは「読み書きが激しく、多少の遅延や反映の遅れを許容できるデータ」と「1件のずれも許されないデータ」に分かれます。1つのDBで両方を賄うと、どちらかの要件を犠牲にするため、性質ごとにストアを分けました。 Amazon DynamoDB ：大量・高速アクセスが求められるキーバリュー型データ（カート・商品カタログ） Amazon Aurora ：整合性が重要なリレーショナルデータ（ユーザー・注文・支払い・在庫） Amazon ElastiCache ：セッション管理とキャッシュ。Auroraの読み込み負荷を軽減 工夫した点 可用性 1つのリージョン 内に AZを2つ 設けるマルチAZ構成にし、リソースを両AZに分散配置しました。片方のAZに障害が発生してももう一方のAZで処理を継続できるようにし、単一障害点を排除することを目的としています。また全世界で使われるサービスのため、リージョンは最もアクセスの多い地域に置く想定です。 セキュリティ ログインや会員情報の扱いは Amazon Cognito に委ねています。「顧客アカウントのセキュリティを厳重にする」という要件に対して、認証を自前で実装するより、実績のあるマネージドサービスに任せるほうが安全だと判断しました。 スケーラビリティ アプリケーションが ステートレス であることを目指しました。セッション情報などの状態を外部（ElastiCache）に保存しておけば、1つのタスクが落ちてもALBが正常なタスクへリクエストを流せるうえ、Auto Scalingでタスクを増減させても、どのタスクでも同じリクエストを処理できます。 Auto Scaling によりFargateタスクを自動で増減させ、特定時間の急激なアクセス集中に対応しました。 運用・ログ管理 ログ管理は演習中に追加要件として提示されたもので、 Amazon Bedrock に質問したり、他のベストプラクティスを参考にしたりしながら、見様見真似でアーキテクチャに組み込んでいます。 最終的には Amazon CloudWatch でログを収集し、Lambdaで「異なるログフォーマットの変換」と「保存するログの取捨選択」を行い、S3へ格納する形にしました。さらにAuroraから QuickSight につなぎ、マーケティングチームが分析できる基盤も構成しています。 改善点 アクセス集中への対応強化 Auto Scalingのスケールアウトには数分かかるため、特定時間に集中するアクセスに対してはスケジュールドスケーリングによる事前のタスク増強を組み合わせるべきでした。また、スケールするのはFargateのみでボトルネックはDB側に移るため、そちらの対策も考えられたらよかったです。 WAF配置の見直し 今のWAFの配置だとALBへの直接アクセスを防げないので、セキュリティを重視するならCloudFrontとALBの両方にWAFを設定する、あるいは、ALB側でCloudFront経由のリクエストのみを受け付けるよう制限するべきでした。 感想 福井 私たちのグループにはAWSに詳しい方がいなかったので、各サービスについて調べ、不明点は運営の方々に質問しながらアーキテクチャを検討しました。そのおかげで、今まで曖昧にしたままだったAWSサービスの役割や使いどころを理解し、知識を定着させることができました。 特に印象に残ったのは、アーキテクチャ設計には決まった正解が1つあるわけではなく、想定するユースケースや重視する要件によって最適な構成が変わるという点です。可用性、アクセス集中への対応、セキュリティなど、 何を重視するかによって選ぶべきサービスや構成の優先度が変わるため、まずは要件を具体的に考えることが重要 だと感じました。 また、ALBやマルチAZ構成、CloudFront、S3などのサービスについても、単に名前や役割を覚えるのではなく、それぞれが どの課題を解決するために使われているのか を意識できるようになりました。改善点の検討では、2AZ構成であっても部分障害時には障害のあるAZにトラフィックが流れ続ける可能性があるなど、 実運用で起こり得る障害パターンまで考慮 する必要があることを学びました。 2日間と短いイベントでしたが、多くの学びがありました。今後AWSを利用したシステムや構成図を見る際には、「どの要件を満たすためにその構成になっているのか」「なぜそのサービスを選んでいるのか」を意識して見ていきたいです。また、今回の構成図に入れていないサービスについても調べ、実務でも活かせる知識として深めていきたいです。 関澤 2日間を通して知らないことだらけで、まさに調査の連続でした。それでも、調べた知識をすぐにハンズオンや設計課題で試せる流れになっていたため、AWSのサービスについてインプットとアウトプットを繰り返しながら学べる非常にいい機会になりました。 特に印象に残ったのは、システム停止に直結する「単一障害点」を排除する Design for Failure の設計思想です。1台のサーバーにすべてを集約する構成から始まり、Webサーバーとデータベースの分離、マルチAZ構成による冗長化へと、フェーズに応じて構成を進化させていく考え方はクラウドサービスならではでした。 また、チームでの設計や他チームの成果発表では、同じような要件に対しても様々なアーキテクティングの工夫があり、参考にしたい点が数多く見つかりました。目的やフェーズによって最適な構成は変わるという考え方は、今後の実務にも活かしていきたいです。  

本稿は、Japan Digital Design 株式会社 佐藤様による「三菱UFJフィナンシャル・グループの DX を牽引する Japan Digital Design、Aurora DSQL の採用で DB コストを約 87% 削減し、運用負荷ほぼゼロを実現」に関する寄稿記事となります。 こんにちは。Japan Digital Design 株式会社 Technology & Development Division で Technical Project Manager を務めている佐藤です。 Japan Digital Design 株式会社は「金融の新しいあたりまえを創造し人々の成長に貢献する」というミッションのもと、AI・CX・Tech の各領域を組み合わせて三菱UFJフィナンシャル・グループの DX を支援しています。私が所属する Technology & Development Division では、システムの開発・運用からプラットフォーム構築、アーキテクチャ設計までを担っています。 今回、ドキュメント検索システムを新規構築するにあたり、データベースとして  Amazon Aurora DSQL  を採用しました。パートナーを介さず自社開発チームのみで導入を完了し、結果として  Aurora Serverless 比で約 87% のコスト削減と DB 運用負荷ほぼゼロ を実現できています。本記事では、私たちが Aurora DSQL を選定した背景、開発時に直面した課題とその対処、そして導入後に得られた効果をご紹介します。これから DSQL の採用を検討される方の参考になれば幸いです。 対象システム Aurora DSQL は、Japan Digital Design 株式会社が運営するドキュメント検索システムの一部である文書管理データベースとして利用しています。 本システムは、夜間バッチ連携される PDF や Web サイトの情報を取り込み・加工し、ユーザーが取込履歴や取込データ一覧を CSV としてダウンロードできる機能を提供しています。 アーキテクチャ 本システムは 2 つのワークロードで構成されています。 夜間バッチ処理 : 翌朝の Web アプリケーションの開局時間までに全ての取り込み・加工処理を終わらせる必要があるため、AWS Step Functions にて約 1,800 の Amazon ECS タスク（EC2 上で稼働）を並列起動。上流から取り込んだデータを各タスクが処理して、取込結果を Aurora DSQL に書き込む Web アプリケーション : Amazon CloudFront + ALB + Amazon ECS で構成された Web アプリケーションから Aurora DSQL のデータを読み取り、取込データ一覧を CSV として提供 夜間バッチでは、 ピーク時に 1 晩あたり 10 万件超 のファイル／レコードを処理します。バッチはユーザーが利用しない夜間にのみ稼働し、日中の Web アプリケーションからの読み取りとは時間帯が分離されています。 データベース選定の背景 本システムは新規開発だったため、システムの特性に合わせてデータベースをゼロベースで検討できました。私たちがデータベースに求めた要件は以下の 3 点です。 1. 複数環境運用におけるコスト効率 本番・ステージング・開発など複数環境を運用するため、未使用環境にも固定費が発生するインスタンス課金型 DB ではコストが見合わないという課題がありました。 2. スパイクワークロードへの対応 夜間に約 1,800 の ECS タスクが並列書き込みを行うスパイクワークロードへの対応が必要でした。書き込みが夜間に集中する特性上、スケーラブルなアーキテクチャが望ましいと考えていました。 3. 将来のデータ拡大への備え 将来的にデータ量を 10 倍規模に拡大する計画があり、その都度性能調査・性能試験を行う工数は避けたいと考えていました。 Aurora DSQL を選択した理由 他の候補として Aurora Serverless、Aurora、DynamoDB を比較検討し、以下の理由から Aurora DSQL を選択しました。 サーバーレス・従量課金 夜間バッチ時のみコストが発生し、未使用環境の固定費を解消できます。Aurora Serverless では、コールドスタートを避けるために最小 ACU を 0.5 に設定すると環境ごとに固定費が発生しますが、DSQL では利用しない環境にほとんど料金がかかりません。 さらに、Aurora DSQL はアイドル状態が長期間続いても接続時の遅延が極めて小さく抑えられます。Aurora DSQL のクラスターライフサイクルでは、一定期間アイドル状態が続くとリソースを縮小（Idle 状態）し、さらに長期間接続がないとリソースをゼロにスケール（Inactive 状態）しますが、接続するだけで自動的に Active 状態に復帰します。一方、Aurora Serverless の自動一時停止機能（0 ACU へのスケーリング）では、再開時に通常約 15 秒、24 時間以上の一時停止後は 30 秒以上の待機が発生します。Web システムでこの遅延を許容できない場合、最小 ACU を 0.5 以上に維持する（＝固定費が発生する）か、定期的な ping 処理でウォームアップを維持する必要があります。DSQL ではこうした考慮が大幅に軽減され、週に 1 回程度しか動かないようなワークロードでも実用的な応答速度で利用できます。 メンテナンスゼロ パッチ適用やキャパシティ管理が不要で、DB 運用負荷を最小化できます。 SQL 互換性 — DynamoDB ではなく DSQL を選んだ理由 DynamoDB も検討しましたが、テーブル設計の特性と SQL 互換性を重視して Aurora DSQL を選択しました。 本システムは業務システムとしてある程度の複雑性を持ちます。DynamoDB でも構築は可能ですが、アクセスパターンに合わせたテーブル設計が求められる NoSQL のアプローチよりも、やりたいことを素直に SQL で表現できる RDB の方が健全なシステムを構築できると判断しました。開発チームの SQL への習熟度が高く、これまでの RDB の知見をそのまま活かせることも大きな要因でした。 そのうえで、RDB の選択肢の中でコスト面で最も優れていたのが Aurora DSQL でした。 スモールスタートから大規模まで、再設計なしに拡張できる 本システムは社内の利用者が使うためのシステムのため、最大ユーザー数は限定的です。Aurora DSQL は GA 当初、マルチリージョンの大規模スケーラビリティが注目されがちでしたが、私たちはむしろ「小さく始められ、必要に応じて再設計なしに大規模まで成長できる」点を評価しました。完全サーバーレスでゼロまでスケールダウンできるため、間欠的・小規模なワークロードでも無理なく利用でき、その後データ量やスループットが拡大しても、同じデータベースの特性・体験のまま使い続けられます。 Aurora DSQL に向いているワークロードかを見極める 採用にあたっては、本システムのワークロード特性が DSQL の設計思想に合致するかを、以下の 3 つの観点で事前に評価しました。DSQL の導入を検討されている方にも、そのまま使える判断基準だと思います。 判断基準 本システムでの評価 楽観的同時実行制御（OCC）で問題ないか 1 タスク = 1 ドキュメントで各タスクが独立した処理対象を扱い、同一レコードへの同時更新が発生しない。さらに書き込み（夜間バッチ）と読み取り（日中）が同時に発生しない OLAP（分析・集計クエリ）のユースケースがないか データの格納と CSV 出力が主用途で、分析・集計クエリは不要 スパイク型ワークロードか 夜間のみ集中した書き込み処理が発生し、日中の負荷は限定的 この 3 条件を満たすワークロードであれば、Aurora DSQL の特性を最大限に活かせると判断し、採用を決定しました。 開発スケジュール 2025 年 5 月末の Aurora DSQL GA（一般提供開始）を受けて検討を開始し、以下のスケジュールで開発を進めました。 時期 マイルストーン 2025 年 6 月 AWS Summit で Aurora DSQL の実動作を確認し、採用検討を開始 2025 年 8 月 事前検証開始（マイグレーションツールの動作確認等） 2025 年 10 月 設計・開発開始 2026 年 1 月 本番ローンチ GA から約 3 ヶ月で事前検証を経て開発に着手し、約 3 ヶ月の開発期間で本番ローンチを迎えることができました。 開発時の取り組みとハマりどころ 私たちはパートナーを介さず、すべて自社開発で Aurora DSQL を導入しました。AWS 公式ドキュメントを主な技術情報源とし、約 3〜4 ヶ月で習熟に至っています。 PostgreSQL 互換とはいえ DSQL 固有の制約はいくつかあり、開発中に検討した内容、および直面した課題と対処法を共有します。 ORM として SQLAlchemy、マイグレーションツールとして Alembic を採用 DSQL を利用する際の ORM とマイグレーションツールの選定前に、ORM とマイグレーションツールによる各 DB 操作で実施できるもの・できないものを一通り確認していきました。その上で、最終的に SQLAlchemy + Alembic を採用しました。 SQLAlchemy については、AWS が公開している aws-samples リポジトリに利用例が掲載されていることが決め手となりました。 https://github.com/aws-samples/aurora-dsql-samples/tree/main/python/sqlalchemy また、SQLAlchemy、Alembic のいずれも必要に応じて生 SQL の実行をサポートしている点も採用理由の一つでした。 大量データのフェッチとメモリ制限 十数万レコードを CSV 化する要件に対して、当初 LIMIT OFFSET 構文による分割取得を試みたところ、トランザクションあたりのワークメモリ上限 128 MiB の制約に抵触しました。LIMIT OFFSET の仕組み上、不要な OFFSET 分のデータもすべて取得してから最終的な結果を返すためです。 対処法: Primary Key として UUIDv7 や連番など一意で時系列なキーを採用しました。データ取得方法についても Keyset Pagination（WHERE 句で前回取得した ID 以降のデータを抽出）に切り替えることで解決可能です。 トランザクションサイズの制限 Aurora DSQL には、トランザクションブロックで変更できるテーブル行の最大数 3,000 件、書き込みトランザクションで変更されるデータの最大サイズ 10 MiB といった制限があります。 対処法: 設計段階からトランザクションサイズを意識し、処理を分割する方式を採用しました。後から気づくと手戻りが大きいため、設計初期にこの制約を織り込んでおくことをお勧めします。 列の変更対応 DSQL では DROP COLUMN、ALTER COLUMN、NOT NULL カラムの追加といった列定義の変更ができません。変更が必要な場合は、別テーブルを用意してデータを移行する対応が必要でした。 ローカル開発環境の整備 現時点では、Aurora DSQL の制約まで再現したローカルエミュレータは存在しません。PostgreSQL コンテナで代替すると、DSQL 固有の制約にローカルでは気づけないケースがありました。 対処法: 制約に抵触しやすい開発モジュールについては、ローカル環境から直接 DSQL に接続して開発する手法を取り入れました。 振り返って：AWS への早期相談は有効 私たちは自社開発のみで導入を完了しましたが、振り返ると、開発段階から AWS アカウントチームに相談していれば、DSQL 固有の制約やノウハウ（フェッチの取り方など）をより早く把握でき、改善要望も早期に提出できたと感じています。AWS 側でも DSQL の制約に関するナレッジを蓄積しており、開発段階から共有いただける体制があるとのことです。これから導入を検討される方には、開発の早い段階でのアカウントチームへの相談をお勧めします。 導入後の効果 コスト約 87% 削減 Aurora Serverless（コールドスタート回避のため最小 ACU を 0.5 に設定した場合）比で、約 87% のコスト削減を実現しました。多数の環境を運用するエンタープライズ案件では、利用しない環境にほとんど料金がかからない DSQL の料金体系により、環境数に比例したコスト増加を回避できています。稼働していなければ放置しても課金が発生しないため、開発環境の上げ下げを管理するバッチ処理やスクリプトも不要になりました。 運用工数ほぼゼロ キャパシティ管理・パッチ適用が不要となり、DB 運用工数がほぼゼロになりました。他のシステムでは、開発環境の上げ下げのバッチ作成、インスタンスの容量拡張、コールドスタート回避のための ping 処理など、細かな運用タスクがどうしても発生します。DSQL ではこれらがすべて不要です。DB 周りの運用管理にリソースがほぼ発生しなくなり、チームは開発や上流工程のタスクに集中できるようになりました。 小規模なシステム、たとえば週に 1 回程度しか動かないようなワークロードでも、コールドスタートなしで即座に応答できる点は、運用の手間を大きく削減してくれています。 データ 10 倍拡大も設定変更・性能チューニングなし データ量を約 10 倍（現在数十 GB 規模）に拡大した際も、DB 側の設定変更や性能チューニングは一切不要でした。DSQL 側には何も影響がなく、性能劣化も発生していません。今後もデータ格納量やバッチ利用時のスループットは拡大していく見込みですが、性能調査や性能試験に時間を取られることなく、DSQL の自動スケーリングで対応できる見通しです。 Multi-AZ 標準装備 デフォルトで Multi-AZ が担保されており、追加設定なしで AZ 障害耐性を確保できています。 総括すると、 コストと運用負荷の削減が Aurora DSQL 導入の最大のメリット でした。環境数がかなり多い本システムでは、利用しない環境にほとんど料金がかからない DSQL の料金体系がマッチしていました。データ量を約 10 倍に拡大した際も、DB 周りは追加の設定変更なく対応できています。 最後に データ格納量やバッチ利用時のスループットは今後も継続的に拡大していく見込みであり、Aurora DSQL の強みを引き続き有効活用していく方針です。また、三菱UFJフィナンシャル・グループ各社への AI 活用展開に向けて、Amazon Bedrock をはじめとする AWS の AI 関連サービスの拡充にも期待しています。 Aurora DSQL 自体に対しては、クエリログ（監査ログ）の実装や ALTER TABLE/COLUMN 対応による列定義変更の柔軟性向上を期待しています。 本記事が、Aurora DSQL の採用を検討されている方の一助になれば幸いです。 執筆者 佐藤 慎 Japan Digital Design 株式会社 Technology & Development Division テクニカルプロジェクトマネージャ Japan Digital Design 株式会社にて金融機関向けシステム・AI導入案件のプロジェクトマネージャを担当。 Amazon Aurora DSQLをはじめとするクラウドネイティブ技術を活用したプロダクトの本番導入に取り組んでいる。

はじめに こちらの記事 で実際にKubernetes環境にKubeBlocksを導入し、DBaaSの基盤を構築しました。 前回の記事 ではKubeBlocksを利用してDBaaS基盤上にMySQLを構築しました。 今回は、KubeBlocksを利用してNoSQLのインメモリデータベースであるRedisを構築していきます。 導入環境構成図 以下の図は、DBaaS基盤上にRedisを導入する環境の構成図です。 「KubeBlocksオペレーター」は こちらの記事 で構築しました。 本記事では、赤丸で囲まれた「DB(Redis)」の構築を対象とします。 Redisはすべてのデータをメモリ上で処理する「インメモリデータベース」の一種で、NoSQLに分類されます。 ディスク（SSD/HDD）にアクセスする一般的なデータベースと比較して圧倒的に高速なのが特徴で、主にWebサイトやアプリの高速化（キャッシュ）や、リアルタイム処理に利用されるDBになります。 導入環境構成図 Redisの構築方法 KubeBlocksを使用してRedisを構築する手順をご紹介します。 今回は最もシンプルな、1台のサーバーでRedisを稼働させるスタンドアロン構成で作成していきます。 前提条件 KubeBlocksが構築済みであること KubeBlocksによってデフォルトでインストールされるRedisアドオン（以下コマンド結果のredis 1.0.1）が有効になっていること 以下のkbcliコマンドで有効化されているアドオンを確認することができます。 kbcli addon list # 出力例 NAME VERSION PROVIDER STATUS AUTO-INSTALL qdrant 1.0.1 community Disabled false rabbitmq 1.0.1 community Disabled false apecloud-mysql 1.0.1 community Enabled true etcd 1.0.1 community Enabled true kafka 1.0.1 community Enabled true mongodb 1.0.1 community Enabled true mysql 1.0.1 community Enabled true postgresql 1.0.1 community Enabled true redis 1.0.1 community Enabled true Namespeaceの作成 まずはRedisをデプロイするNamespeaceを作成します。 kubectl create namespace redis # 出力例 namespace/redis created デフォルトユーザー認証用Secretの作成 Redisのデフォルトユーザー用のユーザー名・パスワードを設定したSecretを作成します。 kubectl create secret generic custom-redis-root-secret \ --from-literal=username='default' \ --from-literal=password='<任意の値>' \ -n redis # 出力例 secret/custom-redis-root-secret created ※Redis作成時に本手順で作成したSecretを指定することで、デフォルトユーザーのパスワードを任意の値で設定することができます。 Secretの指定がない場合は、KubeBlocksがデフォルトユーザー用のパスワードを自動発行します。 Redisの作成 MySQLクラスター構築時と同様に、KubeBlocksのカスタムリソースである「Cluster」のマニフェストを適用し、Redisを作成します。 cat <<EOF | kubectl apply -f - apiVersion: apps.kubeblocks.io/v1 kind: Cluster metadata: name: redis-cluster namespace: redis spec: terminationPolicy: Delete clusterDef: redis topology: standalone componentSpecs: - name: redis replicas: 1 systemAccounts: - name: default secretRef: name: custom-redis-root-secret namespace: redis serviceVersion: 8.0.3 disableExporter: false resources: limits: cpu: "0.5" memory: "0.5Gi" requests: cpu: "0.5" memory: "0.5Gi" volumeClaimTemplates: - name: data spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi EOF # 出力例 cluster.apps.kubeblocks.io/mycluster created clusterDef: redis Redisアドオンが提供するRedisの構成テンプレートを、作成するDBクラスターのベースとして指定する設定です。 topology: standalone Redisを単一のRedisサーバーインスタンスで構成されるスタンドアロンクラスターとして起動する設定です。 terminationPolicy: Delete クラスターを削除した際、関連するデータも一緒に削除する設定です。 systemAccounts Redisのデフォルトユーザーの認証情報（ユーザー名・パスワード）に、事前に作成したSecretを割り当てる設定です。 volumeClaimTemplates DBのデータを保存するためのPVの設定です。 Redisの作成確認 Redis作成コマンド実行後、以下のコマンドでクラスター・Podのステータスを確認します。ステータスがRunningになっていれば正常に動作しています。 kubectl get cluster redis-cluster -n redis # 出力例 NAME CLUSTER-DEFINITION TERMINATION-POLICY STATUS AGE redis-cluster redis Delete Running 110s kubectl get pods -n redis # 出力例 NAME READY STATUS RESTARTS AGE redis-cluster-redis-0 4/4 Running 0 2m15s 動作確認 Redisへの接続テストを行います。 まず、作成したRedisのエンドポイント（Service名）を確認します。 kubectl get svc -l app.kubernetes.io/instance=redis-cluster -n redis # 出力例 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE redis-cluster-redis-redis ClusterIP 10.43.163.160 <none> 6379/TCP 3m kubectl runコマンドでRedisクライアント用のPodを作成し、コンテナ内でシェルを起動します。 kubectl run redis-client -n redis --rm -i --tty --image=redis:8.0.3 --restart=Never -- bash # 出力例 If you don't see a command prompt, try pressing enter. root@redis-client:/data# redis-clientコマンドを使用し、確認したRedisのエンドポイント、「 デフォルトユーザー認証用Secretの作成 」で作成したユーザ名・パスワードを指定して接続します。 root@redis-client:/data# redis-cli -h redis-cluster-redis-redis.redis.svc.cluster.local -p 6379 --user default --pass xxxxx # 出力例 Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. redis-cluster-redis-redis.redis.svc.cluster.local:6379> Redisに正常に接続できているか、以下のPINGコマンドを使用して確認します。 redis-cluster-redis-redis.redis.svc.cluster.local:6379> PING # 出力例 PONG 「PONG」が出力されれば、正常に接続できています。 続いて、データの登録・取得が行えるかを確認します。 キー「test」に値「”Hello World” 」を登録します。 redis-cluster-redis-redis.redis.svc.cluster.local:6379> SET test "Hello World" # 出力例 OK 登録したデータが正しく取得できるかを確認します。 redis-cluster-redis-redis.redis.svc.cluster.local:6379> GET test # 出力例 "Hello World" 登録した「”Hello World” 」という文字列が出力されれば、Redisへのデータ登録と取得は正常に行えています。 これでRedisの構築と動作確認は完了になります。 おわりに 前々回構築したKubeBlocksを使用し、実際にRedisの構築から接続テストを行うまでの流れをご紹介しました。 前回のMySQL構築に引き続き、容易にRedisを構築できることを体感できたのではないでしょうか 。 今回は最もシンプルな「Redisサーバ1台のスタンドアロン構成」として構築しましたが、KubeBlocksなら本番環境向けの冗長構成も、マニフェストの設定を少し変更するだけで簡単に構築することができます。 KubeBlocksは様々なDBをサポートしているため、他のDBも同様の方法で手軽に導入することができます。 本記事が、Kubernetes上でDBを構築する際の選択肢として、KubeBlocksを検討するきっかけになれば幸いです。 参考文献 https://kubeblocks.io/docs/preview/kubeblocks-for-redis/03-topologies/01-standlone https://kubeblocks.io/docs/preview/kubeblocks-for-redis/06-custom-secret/01-custom-secret ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post KubeBlocksでRedisを導入！Kubernetes上での高速キャッシュ/NoSQL構築を体験 first appeared on SIOS Tech Lab .