Group私は過去12ヶ月の間に(a)クラウドベースのインフラストラクチャを使うことに踏み出していない、もしくはその様なチームがいない(b)2018年のロードマップにクラウドを使うことが乗っていないクライアントに会っていません。Ownership(TCO)の節約は無視できません。Groupでは、インフラストラクチャの95%以上が2014年後半からAWS上で稼働しています。過去数年にわたり、多くのお客様に機転となる時に何を期待しているかをアドバイスしました。私達はマーケティングデータベース管理サービスを提供しています。クライアントとの最も一般的な議論の1つは、リレーショナルデータベースをAWSに移行する際に抱えるメリットと課題を理解する助けとなることです。100クライアントのために完成した代表的なプロジェクトを中心に、データベースクラウドの移行に関する会話行っています。この特定のクライアントにとって、私たちは最初に、データセンターのハードウェア上にMySQLデータベースを構築しました。MySQLに移行をしました。クライアントのユースケースと基本的なデータスキーマは、この間にあまり変化しませんでした。そのため、私たちはソリューションの管理がますます効率化されるようになるにつれ、同じMySQLデータベースを複数のフレームワークで実行することの長所と短所について多くのことを学びました。今回の対象のデータベースは、マーケティングおよびセールスカスタマーリレーションシップマネジメント(CRM)データベースでした。一連の電子メールおよびセールスチームベースのマーケティングキャンペーンで、レポートおよび分析ユースケースのために複数のサードパーティソースにデータを継続的に集約しました。私たちのチームは、データベースの管理に加え、マネージドサービスとしてレポートと分析の提供を担当する主なユーザーです。このプロジェクトは、スコープと予算の面で一般的に管理していた物の小規模なものでした。Aurora次の移行の概要では、各バージョンへの移行の決定と、その過程で得た利点と課題について説明します。オンプレミスハードウェア上のLinuxでMySQLを実行する2013年後半にこのクライアントとの関係を開始したとき、クラウドベースのサービスを検討し始めましたが、私たちのインフラストラクチャは、データセンターを基盤とするハードウェアソリューションでした。クライアントサービスや厳しい締め切りで働いている多くの人が理解できるように、理想的な長期的なソリューションを最初から構築するのではなく、迅速に稼働させることを優先する必要がありました。私たちは、オンプレミスハードウェア上のLinuxとMySQLの組み合わせから開始することにしました。これは、このプロジェクトで作業しているエンジニアが最も慣れている構成だったからです。MySQLの構成でよく作業していたことです。必要な開発フレームワーク、データ転送メカニズムなどはすべてかなり理解されており、大きな技術的驚きは期待できませんでした。これにより、限られたAWS経験を持つクラウドベースのソリューションに飛び込むのとは対象的に、納期と予算に対するリスクを最小限に抑えながら顧客の設定した期限を迎えることができるという自信が得られました。チャレンジしかし、ハードウェア環境で解決策を維持することには、かなりの数の問題がありました。AWSへの移行を後で行うまでは、これらの非効率性を十分に理解していませんでした。時間の経過とともに増加するデータ量に対応する、シームレスではない垂直スケーリングプロセススナップショットを復元する必要があるときはいつでも、より多くの手動リカバリプロセスを必要とするカスタムバックアッププロセスを実装する必要性ハードウェアに障害が発生する可能性のリスク現在、成熟したクラウドベースのソリューションと比較して、ハードウェアベースのソリューションの欠点はかなりよく理解されていますが、2014年初頭ではあまり理解されていませんでした。EC2上のLinuxでMySQLを実行する2014年中頃までに、私たちは、指数関数的に増加するデータ取り込みと複数のクライアントの分析ユースケースによって、データセンター全体を大幅に拡張する必要がありました。AWSのコスト計算を使用して、クラウドをハードウェアソリューションと比較してベンチマークを行い、簡単なTCO分析を実施しました。ハードウェアインフラストラクチャを継続的に拡張するのではなく、AWSへの大規模な移行を行うことで、大幅かつ迅速な節約を実現できることがわかりました。エンジニアリングチームの長い議論の後、物理的なデータセンターソリューションとクラウドプラットフォームの両方をコスト効率よくサポートできないと結論づけました。クラウドに移行するならば、すべてのサービス​を移行する必要がありました。私たちは一度に行わなければならない変更の数を制限する必要がありました。そこでAuroraのようなマネージドデータベースソリューションに直接飛び込むのではなく、データセンターで実行していたものと同じバージョンのMySQLを実行するLinuxベースのOSを使用して、現在のクライアントのMySQLデータベースをEC2インスタンスに移行しました。利点この移行により、すぐに2つのメリットが実現出来ました:まず、ハードウェアベースのデータセンターと比較して、インフラストラクチャのコストが大幅に下がりました。これは、コロケーション費用、追加のハードウェア費用、および実行中のハードウェアに付属するその他すべてのコストを考慮した後です第2に、ますます増大する第三者のデータソースに対応するためにソリューションを垂直方向に拡張することは、本当にシームレスになりました。物理的にデータセンターに行ったり、ハードウェアを追加したり、新しいサーバーを設置・プロビジョニングする必要がなくなりました。いくつかのコマンドを入力するだけで、瞬間的に10〜100GBを拡張することが出来ます。EC2には、この特定のクライアントのための移行からは得られませんでしたが、他にも利点があります。公平にするために、これは私たちのユースケースにはあまり必要とされないものでした。複数のアベイラビリティゾーンを持つことで得られる追加の冗長性を必ずしも必要としませんでした。AWSをあまりご存知出ない方のために説明すると、AWSのリージョンには複数のアベイラビリティゾーンがあり、各アベイラビリティゾーンは別々の施設で構成されています。万が一1つのアベイラビリティゾーンに障害が発生した場合は、別のアベイラビリティゾーンに迅速にサービスを展開できます。今回のユースケースでは、99.99%の稼働率と可用性を備えたソリューションは必要ありませんでした。私たちが構築していたソリューションの主なユーザーはわずか2〜3人でした。レポート分析は、オンデマンドである必要はなく、24〜48時間のウィンドウ内でアドホックに完了することができました。クラウドサービスへの最初の大きな移行であったため、多くの1回限りの学習曲線の問題がありました。今ではエンジニアリングチームの誰もが、従来のハードウェアスタックよりも、サーバーの調達、ネットワークの管理、AWSによるデータのバックアップなどの作業を大幅に簡単に行うことに同意しました。これらのことをシームレスに行う方法を学ぶためには、まだ少し経験がが必要でした。EC2のセットアップでは、サーバーにパッチを当てて、手動でデータベースのアップグレードを実行して、クライアントと操作手順およびサービスレベル契約に沿った状態を維持する必要がありました。Aurora2015年の残りの期間で、クライアントのために多数の新しいデータパートナーを導入しました。私たちにあまり綺麗になっていないデータを送信して、データの品質チェックを何とする義務がありました。サードパーティのデータプロバイダを扱う多くの人が経験していると思いますが、ベンダーは以前に問題を処理していた方法を上書きする新しい例外を導入することに堪能でした。これにより、クライアント用に構築したデータベース内で整合性の問題が発生することがありました。これは、処理前のポイントから手動でリストアする必要があります。そのため、私たちは、バックアップとポイントインタイムのスナップショットプロセスを維持することよりもはるかに多くの時間を費やしていました。EC2インスタンスでMySQLを実行することは、既存のチームがクラウドサービスのコア機能がどのように機能しているかを理解する上で非常に重要な出発点でした。Auroraに移行する時が来たと考えました。更新、アップグレード、バックアップ/リストアプロセスなど、メンテナンスのための組み込み機能を利用できます。利点Auroraへの直接的な移行が必要でした。Auroraへの移行は、当社のソリューションを維持する上で残った非効率性の大半を取り除きました。エンジニアとDevOpsチームは、ポイントインタイムリストア処理の手動コンポーネントから大幅に解放されました。EC2ソリューションからAuroraへの移行はかなりシームレスでした。Consoleで数回クリックするだけで完了するようになりましたAuroraは、私たちの特定のクライアントのユースケースに対して効果的に動作します。これは、小規模なレポーティングと分析プロジェクト用にMySQLを実行するリレーショナルデータベースを構築する必要があるときは、今では標準のソリューションです。2016年中頃に初めて移行を完了したとき、サーバーと使用状況ログに定期的にアクセスする方法は不明確でした。Lambdaのようなカスタムジョブを設定して実行する必要がありました。CloudWatchに直接データを送信することを可能にした最近のアップデートで部分的に対処されています。Redshiftのようなアナリティック・データベース製品には、ログ・アクセスが組み込まれているようです。このユースケースではAuroraはうまく機能しましたが、すべての問題を解決出来るソリューションはないことを覚えておくことが重要です。我々は、アドバンテージが、ソリューション開発と継続的なメンテナンスのコストを上回るかどうかが不明確な多くのケースでAuroraの仕様を検討しました。マルチリージョンのサポートと何千もの同時書き込みを必要とする消費者向けソリューションをサポートするには、SSDストレージ・オプションを使用して構築されたソリューションをカスタマイズし、複数のインスタンスを作成したり、シャーディングしたりする必要があります。これには多大な手間がかかり、継続的なメンテナンスが複雑になる可能性があります。ここでの非効率性の仮定は部分的な情報に基づいた意見です。Multi-Masterという機能を発表しました。この機能はこの種のユースケースに適しています。私達はハードウェアももう使いませんクライアント向けにこのソリューションのバージョン1.0を初めて完成してから4年が経過しています。最初にデータベースをAWSに移行してから3年が経過しています。DynamoDBからAuroraまで、提供されているほとんどすべてのサービスとフレームワークで、数多くのAWSに関するデータベース関連プロジェクトを様々なクライアントに向けて完了しました。最初のいくつかのプロジェクトでクラウドに移行する初期の学習の後、私はクライアントの技術チームの中でAWSの最大の主張者の1人になりました。Auroraのようなマネージド・ソリューションでは、単なるコスト削減以上のメリットがあります。当社のエンジニアおよびDevOpsチームは、メンテナンス、アップグレード、およびリカバリプロセスの時間を60〜80%削減し、クリエイティブな時間に当てています。翻訳は星野が担当しました。機会均等法を順守しています。平等に採用しています。