「オンプレミスの納品」「スケールアップ運用解消」に必要な思考フロー　課題から「本当にしたいことは何か」を掘り下げて解決

相談3：オンプレミスへの納品がしたい

齋藤祐一郎氏（以下、齋藤）：バトンを引き継ぎまして、齋藤からご案内いたします。3番目のテーマです。エンタープライズ企業からの要望で、オンプレミスのデータセンターへ納品をしたいという要望を時々もらいます。

特にBtoBのSaaSを提供しているスタートアップ企業から、このような相談をよく受けます。エンタープライズ企業側から、オンプレミス版をカスタマイズで提供してほしいというのが、最初の相談内容です。

実際、これはどういうことなんだろうと掘り下げていくと、エンタープライズ企業側のセキュリティ基準を守りながら、安心してサービスを提供できるようにしたいというところや、オンプレミスに導入したとしても、最終的にはサービス提供側からアプリケーションを管理可能にするかたちで導入したい、というところに着地すると思っています。

そこで、私からも思考パターンを3つ案内できたらと思います。

まず3つの案内の前に、エンタープライズ企業側がどのような懸念を持たれているのかを確認していければと思います。

やはり、額面どおりにエンタープライズ企業にオンプレミス版を導入すると、カスタマイズや導入の際に、現地に行って作業をしなければいけなかったり、アップデートも当然現地での作業なので、せっかくクラウドサービスで提供して、敏捷性＝アジリティを確保しているのに、なかなか状況が難しくなってきます。

だけど、エンタープライズ企業側がオンプレミスを希望するのは、実は1つの例だったりするわけです。なので、どうしてオンプレミスなのかをぜひ商談の時に聞いてみてください。これはエンジニアの方と営業の方、同時に聞くのがポイントです。まず聞き方ですが、私たちは大きく3つほど聞いてみてくださいと案内しています。

1つ目は、どのような懸念を持たれているかというところです。実際、オンプレミスのデータセンターに入れてほしいということは何か懸念を持っていると思うのですが、そこに寄り添っていただきたいです。

2つ目に、クラウドサービスを導入するのは、スタートアップ企業にとっては、もはや常識のようにしてもらっていて、本当にうれしいことです。しかし、世の中では、オンプレミスで導入している方もまだまだいます。そういう方にオンプレミスではなく、クラウドサービスを使う際に、社内で規定を持っている会社もあります。オンプレミスとは違うルールを持っているということです。

その場合、外部発注の際の規定や、各種あるAWSのサービスの中で、使っていいAWSサービスが決められている会社もあります。あと、一番気にされているところで、保存しているデータをどうやって管理しているかという点です。きちんと規定があれば、この点を聞いてみてください。

3つ目に、これは聞きやすいかと思いますが、他にSaaSのクラウドサービスを使っている場合は、どのように使っているのかです。要するに事例があれば、その事例の軌道に乗れば提供しやすいので、そういうふうにやってみるということです。

ステップ1：自社の運用体制を整える

さっそくですが、最初に技術の話というよりも、まずコンプライアンスやセキュリティの準備の話です。スタートアップ企業にぜひここは伝えておきたいと思うのですが、エンタープライズ企業にとっては、スタートアップ企業は内部統制が発展途上だと思われている節があります。実際に、これからいろいろと構築しなければならない会社もありますが、もちろんやる気もあると思うのです。そこで、その先入観を取り払うためのプロセスを、実はAWSでは用意しています。

それは、AWS Well-Architected Frameworkと言います。これは、AWSは世界中でスタートアップ企業からエンタープライズ企業、そのほかのさまざまな業界のお客さまに使っていただいた中で、クラウドの設計、運用のベストプラクティスなどを蓄積しています。

AWSではAWS Well-Architected Toolという、実際にチェックを入れていくツールがあるのですが、こちらを使ってレビューをしてもらい、必要があれば改善をしてもらって、レビューの結果をもとにエンタープライズ企業に説明できる状態を作ってください。

AWS Well-Architected Frameworkには5つの柱があります。運用の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化です。（スライドを示して）特によく聞かれるのが運用の優秀性、セキュリティ、信頼性の3つです。もっと絞るとセキュリティです。ここをまずきちんとレビューをしていただいて、みなさんがどういう立ち位置にあって何をしていけばいいのか、そして、何を伝えればいいのかを確認するようにしてください。

このレビューはAWSの私たち、ソリューションアーキテクトが一緒になってレビュー会を立ち上げることもできます。また、相談にも応じますので、必要であればお問い合わせください。

ステップ2：閉域網で接続可能なサービスの利用を検討する

2つ目は、閉域網の話です。パブリックネットワークを経由せずに通信できます。エンタープライズ企業では、やはり外の通信をしてほしくないという話が出たりします。先ほど松田さんからも案内がありましたが、VPC（Virtual Private Cloud）同士をつなぐのは、別のお客さま同士でもつなぐ方法があります。

御社側、スタートアップ企業のAWSアカウント、そして、エンタープライズ企業側のAWSアカウントそれぞれをつなぐためにAWS　PrivateLinkを活用することです。

ステップ3：サービス提供側からメンテナンス可能な仕組みを考える

3つ目は、やむを得ずエンタープライズ企業側のオンプレミスに導入する場合です。これに（合うものとして）Amazon ECS Anywhereというサービスが最近登場しました。こちらはエンタープライズ企業のデータセンターに、スタートアップ企業のAWS環境からECSクラスタを参照できるようにします。要するに、あたかもECSクラスタがあるように見えるようにします。スタートアップ企業側から、エンタープライズ企業のアプリケーション管理をする状態です。

こうすると、監視やアプリケーションのアップデートをスタートアップ企業側で統括できるようになって、例えばデータセンターに行く手間も大きく省けます。これでエンタープライズ企業側は自分たちで使えるようになります。

（スライドを指して）資料はこちらを公開しますので、ぜひご利用ください。

相談4：Amazon RDS/Auroraをスケールアップする運用を辞めたい

4つ目に、これもよく聞く話ですが、Relational Databaseのスケールアップする運用をやめたいという課題です。Amazon　RDS/Auroraを使っている方から、よく質問があると思います。

うれしいことに事業が伸びてきて、どんどんデータベースをスケールアップを繰り返しているけれども、だんだんコストがかさんできたとか、突然応答がなくなったと、よく聞きます。けっこう大変ですよね。

スケーラブルなプロダクトにしたい。Relational　Databaseをスケーラブルに持っていきたい気持ちがあると思います。

では、どういうふうにやっていくのか。今回は段階を1つ増やして4つにしました。まずはエンジニアの方だとよく聞く言葉、「推測するな、計測せよ」です。

Amazon RDS、Amazon AuroraにはRDS Performance Insightsという統計を取るツールがあります。これは何の統計を取るのかという話ですが、SQLがどれだけ発行されているのか、どのぐらいの秒数がかかっているのか、そして、ちゃんとIndexが効いているのかどうかというエクスプレインド結果からも調査できます。

特によくパフォーマンス劣化のポイントになるのが、Indexが効いていなくて、参照コストが高いSQLです。アプリケーションを作っていると、だんだん仕様変更でフェア分が増えたりすると思いますが、カーディナリティが非常に高いのに、WHERE句がうまく入っている感じになることがあると思います。

あと「N+1」や、集計関数を使っていて、負荷が高いというのもあると思います。そういうのをまず見つけてもらって、それに対処してからITインフラに手を入れていきましょう。

ステップ1：リードレプリカを追加する

最初に、リードレプリカを追加するという対策です。Amazon RDS/Auroraにはリードレプリカ、参照専用のデータベースサーバを追加できます。（スライドを指して）ここはAuroraのライターですが、通常1台で動かしていると、読み書きのサーバーに対して、エンドポイントに対してアクセスはアプリケーション化されていると思います。

ここに読み込み専用のリードレプリカを立ててもらい、（ホスト名が違いますが）読み込み専用のエンドポイントにアクセスしてもらい、書き込むためのデータベースサーバーの負荷を総体的に下げる対策をしてもらいます。

そうすると、特にECサイトをしている方ならわかると思いますが、基本は参照のほうが多いと思います。参照クエリの問い合わせの負荷を減らして対応するということです。

ただし1つだけポイントがあります。（スライドを指して）ここの傾向にも示したとおり、Readオンリーのエンドポイントは別です。実装を変えなければいけないのではないかという話がありますが、実はRuby on Railsを始めとしたWebアプリケーションフレームワークには、読み込み専用のエンドポイントを設定するものがあります。

参考資料にリンクを貼っているので、そういうWebアプリケーションフレームワークと連携させて使ってもらえればと思います。

ステップ2：キャッシュを活用する

次はキャッシュです。Relational Databaseの参照問い合わせをキャッシュにためます。大きく分けてキャッシュは方法が2つあります。1つはSQLの問い合わせ結果をキャッシュする方法と、もう1つはページのレンダリング結果をキャッシュする方法です。

1つ目は、Amazon ElastiCacheを活用することです。これはSQLの問い合わせ結果をメモリにキャッシュして、Relational Databaseの参照問い合わせの負荷を相対的に下げます。気をつけなければならないのは、Relational Databaseの元データが更新された時には、そのキャッシュのデータを破棄する必要があります。そうしないと狂ってしまいます。

2つ目は、レンダリング結果のページをキャッシュします。これはAmazon CloudFront、いわゆるCDN（Content Delivery Network）をキャッシュします。そうすると最終的にアプリケーションにも負荷が行かなくなるので、アプリケーションおよびデータベースの負荷が下がります。（スライドを指して）こんな感じですね。このように使ってもらうといいかと思います。

ステップ3：書き込み不可を下げる

3つ目は、書き込みです。書き込み負荷を下げる方法もあります。普通、書き込みをすると、Webアプリケーションが複数同時に動いているので、何十何百と同時にRelational Databaseのライターサーバーにアクセスすることになります。そうすると、書き込みのトランザクションが輻輳するケースも中にはあるかと思います。

その場合、急にためて処理を直列化します。要するに、いったんバッファリングして全員並べてもらう。そして、Relational Databaseの書き込みの負荷を相対的に下げるものです。これはAmazon　SQSというサービスでできます。

ステッ4：NoSQLを使う

4つ目に、即時性が求められる書き込みが多量に発生することです。私はもともとFintechのサービスを作っていましたが、例えば、決済やゲームのプレイデータ、チャットデータなどは、キューイングしているとどうしても非同期で書かれるので、遅れることがあります。

サービスの体験が下がるのであれば、Relational DatabaseでNoSQLを使い始めることを検討してもらいます。なぜかと言うと、Relational Databaseは、方法はいろいろありますが、原則ライターは1つしか立てられないため、書き込みの対策には基本スケールアップしかないので、NoSQLを使うということです。

NoSQL、特にDynamoDBの特徴というのは、書き込み処理自体をデータベースマネジメントシステム側でスケールできます。そうすると、書き込み自体を大量に同時にできるようになります。（スライドを指して）こういう感じですね。

もちろん全部DynamoDBにやってもらってもいいのですが、移行する場合は、もともとのデータは移行しなくてもいいユーザーマスターなどは、Auroraのままでもよいかと思います。

参考資料です。こちらも合わせて実装時に参考にしてもらえればと思います。

悩みがあったらソリューションアーキテクトに相談を

まとめです。今日は4つ話をしました。1つ目は、単一のアカウントを分けることです。これで開発、運用、アプリケーション別で管理をしやすくします。

2つ目は、CI/CDを簡単にすることです。最近は出来合いのCI/CDフレームワークがあるので、そちらを活用して、アプリケーションのデプロイをより自動化して、みなさまの手間を省きつつ事故も減らしてほしいです。

3つ目は、エンタープライズ企業からの要望でオンプレミスの納品がしたいという場合に、オンプレミスという言葉に惑わされず、エンタープライズ企業側の懸念を噛み砕いて、その不安を払拭するように閉域網などで実装するといいのではないかと思います。もちろん説明を尽くした結果、現状のままでも大丈夫というケースもあります。

4つ目はデータベース、Relational Database、Amazonrds RDS/Auroraをスケールアップする運用をやめるために、負荷分散の方法や、NoSQLの使い方について案内をしました。

ここまでいろいろと話してきました。過去のものも含めて秋期講習、春期講習の資料の案内をしています。もしお悩みのことがありましたら、私たちソリューションアーキテクトにぜひ気軽に相談してもらえればと思います。担当者経由でお呼びください。基本SAの相談は無料ですので、ぜひ遠慮なくご連絡をもらえればと思います。

本日はお忙しい中、ご聴講いただきどうもありがとうございました。これにて本セッションは終了します。

松田：ありがとうございます。