ミスった設計から始まる悪夢

実は、ある会社でRDS関連のところでアンチパターンで設計されていたことで、規模が大きくなってきた時にRDSが落ちて休日にサービスが止まってしまったという悪夢のような現実が起こったことがあります。その時、関わっていて、ちょっとお勉強をしたときに、アンチパターンを調べたままだったので、まとめてみました。ぜひ、反面教師として、お使いください。

RDSに興味がある人がこの記事の対象です。

前提として、サービスの規模によってはアンチパターンをわざと採用して、コストを削減することもあります。しかし、あくまでもアンチパターンのため、なるべくベストプラクティスの方向性で書いてみようと思います。

RDSとは

Amazon RDS（Relational Database Service）は構築や運用を容易にするリレーショナルデータベースサービス。AuroraやDynamoDBとか使っている時は、RDSを使っているということです（RDSのデータベースエンジンの1つがAuroraやDynamoDB）。AWSを使用していて、DBをクラウド上においている場合は、使っていることが多いでしょう。

【アンチパターン1】
RDSとEC2/Lambdaの組み合わせにおけるデータ転送

RDSとEC2やLambdaとのきみ合わせにおいて、データの転送の仕方を以下のようにしてしまうと非効率でRDSに影響が出てくることがあります。

やるな！APIの呼び出しすぎ

EC2インスタンスやLambda関数からRDSへのクエリが頻度高く、実行される場合にRDSに負荷をかけることがあります。例えば毎秒100回のクエリが実行される想定で考えると、高い頻度のクエリは、RDSインスタンスのCPU使用率をものすごい勢いで増加させることがあります。実際に僕自身も業務でそのグラフを見たことがあり、ビビりました（笑）通常のCPU使用率が10%だけど、過剰なクエリにより50%以上に跳ね上がったりもします。

やるな！不要なデータ転送

EC2インスタンスやLambda関数が、必要以上に大きなデータセットをRDSから取得する場合、必要なデータが1MBのにも関わらず、10MB以上のデータを毎度のこと、転送している場合があったりします。不必要なデータを送ること自体そもそもよろしくないのは前提で、こうしたことをするとデータの量に依存して、不必要な帯域幅を消費し、RDSのI/O(Input/Output)パフォーマンス（スループット・IOPS（Input/Output Operations Per Second・レイテンシー（遅延時間）・キューの深さ）に影響を与えます。

どうなる？

CPU使用率の爆上がり
→ 過剰なクエリはRDSインスタンスのCPU使用率を高め、他の処理に対する影響やレスポンス時間の遅延を引き起こります。
メモリの圧倒的消費量を更新
→ 特に、データのサイズが大きい場合や複雑なクエリを頻繁に実行する場合、RDSインスタンスのメモリ使用率が増加し、パフォーマンス低下の原因となります。
ネットワーク遅すぎ
→ 不要なデータ転送はネットワークトラフィックを増加させ、データ転送時間の増加や他のサービスへの影響をもたらします。

あんまり、RDSをいじめないでください⚠️

【アンチパターン2】
S3やセキュリティ設定アンチパターン

AWSサービスを組み合わせる際に、適切なIAMポリシーやセキュリティグループを設定しないことは、セキュリティリスクを高めるアンチパターンです。以下は、このような状況の具体的な例と、それぞれのサービスの簡単な説明です。

やるな！EC2インスタンスのセキュリティグループの不適切な設定

EC2インスタンスのセキュリティグループで、SSH (ポート22) をインターネットからのアクセスに対して完全に開放する設定にしていたとします。この設定により、インターネット上の任意のアドレスからEC2インスタンスへのSSHアクセスが可能になり、攻撃者からブルートフォース攻撃（無作為にユーザー名とパスワードを試す攻撃）やディクショナリー攻撃（一般的なパスワードのリストを用いる攻撃）などの攻撃をしやすくなります。そういった不正アクセスで、サーバーの侵害リスクが高まります。

やるな！S3バケットの公開アクセス設定

機密データを含むS3バケットのアクセスポリシーをパブリックに設定の状態だとした場合、ネット上の誰もがそのバケット内のデータにアクセス可能となります。バケット内の顧客データ、財務データ、個人識別情報などの超！超！超！機密な情報が公開されることになります。悪意のあるユーザーはこれらの情報を入手できたりもします。実際やろうと思えばできるようなサービスを見かけたことがあります...

どうなる？

機密情報の漏洩、マルウェアのインストール、その他のセキュリティ侵害が発生する可能性もあります。また、侵害されたインスタンスはさらなる攻撃の踏み台として使用され、被害が拡大することもあります。最悪の場合、データ漏洩なども起こり、顧客信頼を失ったり、最悪の場合は法的責任なども発生するかもしれません。

【アンチパターン3】
ECSなどとの依存関係によるアンチパターン

やるな！Elastic BeanstalkのアプリケーションでのRDS単一インスタンス依存

あるElastic Beanstalkでホストされるウェブアプリケーションが、トラフィックの増加に伴い月間アクティブユーザーが10万人から50万人に増加するとします。このアプリケーションが単一のRDSインスタンスに依存している場合、データベースの負荷が急増しちゃいます...そうすると、アプリケーションのパフォーマンスが著しく低下し、レスポンスがものすごく遅くなる可能性があります。また、ピーク時にRDSがダウンしてサービスが一時的に停止してしまうかもしれません。

やるな！ECS/EKSでのRDS単一インスタンスへの過度な依存

AWSのECS（Elastic Container Service）またはEKS（Elastic Kubernetes Service）を使用して、数十のコンテナ化されたマイクロサービスを実行している状況を考えます。これらすべてのサービスが同じ単一のRDSインスタンスに接続しているとします。単一のデータベースインスタンスが過負荷になり、クエリの遅延やタイムアウトが頻発するような現象が起こります。特に、データベースへの書き込みや読み込みが集中すると、パフォーマンスの問題が顕著になる可能性があります。

どうなる？

ユーザーエクスペリエンスの低下により、顧客満足度が損なわれ、サービスの評判に悪影響を与える可能性があります。また、サービス全体の可用性と信頼性が低下し、顧客に対するサービス提供に支障をきたすことがあります。また、データベースの障害はシステム全体のダウンタイムが発生し、機会損失を引き起こすかもしれません。

最後に

「あんまり、RDSをいじめないでください。」