Category: Compute

この投稿では、当社が受け継いできた関係データベース上に構築されたデータウェアハウスの代替としての、cloud-nativeデータウェアハウスの設計についてお話します。 設計過程のはじめで、最も簡単に見える単純なソリューションは、関係データベースから他のものへのリフト＆シフトマイグレーションです。しかし、当社は一歩戻り、まずはデータウェアハウスで何が本当に必要とされているかに焦点を当てることに決めました。当社はどのようにして、正しいツールを適した業務に使用することにより、従来のオラクルデータベースをより小さなマイクロサービスに分離できるかに着目し始めました。当社の方法はAWSツールを使用するだけではありませんでした。さらに、それはcloud-native技術を使用して当社を最終状態に持っていくためにマインドシフトすることでした。 このマイグレーションには既存データもマイグレートさせながら新規のデータを流入させるために、新規の抽出、変換、ロード(ETL)パイプラインが必要でした。このマイグレーションのため、AWS Glueに統合されることにより、当社は多くのサーバーを除去し、完全にサーバーレスのデータウェアハウスに移行することができました。 このブログ投稿で、当社は以下をご覧に入れます： 当社がデータウェアハウスのためにサーバーレスデータレイクを選択した理由。 Woot’sシステムのアーキテクチャー図。 マイグレーションプロジェクトの概要。 当社のマイグレーションの結果。 アーキテクチャーおよび設計の関係 こちらは当社が考慮した設計重点の一部です： 顧客体験。当社は常にお客様が必要とすることから始め、そこから戻るように業務を行いました。当社のデータウェアハウスは様々なレベルの技術専門性を持った人々による事業を渡って使用されます。 当社は異なるタイプのユーザーが運用の中に識見を持つ能力に焦点を当て、全体的な顧客体験を向上させるために、より良いフィードバックメカニズムを提供します。 最小限のインフラストラクチャーメンテナンス。「Wootデータウェアハウスチーム」は本当にたった一人の人です-Chaya! このため、当社がcloud-native技術を使用することができるAWSサービスに集中することは当社にとって重要です。これらは需要が変化し、技術が進化するにつれ、未分化性のインフラストラクチャーの管理といった困難な仕事を取り除きます。 データソースの変化に対する応答性。当社のデータウェアハウスは内部サービスの範囲からデータを取得します。弊社の既存のウェアハウスでは、これらのサービスへのいずれの更新でETL業務および諸表で手動による更新が必要でした。これらのデータソースのための応答時間は当社の主要関係者にとって重大なことです。このために当社は高性能アーキテクチャーの選択に向けたデータ主動のアプローチが必要でした。 生産システムからの分離。当社の生産システムへのアクセスは固く結びついています。複数のユーザーを許容するため、当社はそれを生産システムから分離し、複数のVPCsでのリソースをナビゲートすることの複雑さを最小化する必要がありました。 これらの要件に基づき、当社は運営面およびアーキテクチャーの面の両方で、データウェアハウスを変更することを決定しました。運営の観点から、当社はデータ摂取の目的で新規の共有応答モデルを設計しました。アーキテクチャーの面で、当社は従来の関係データベースに代わってサーバーレスモデルを選択しました。これら2つの決定は、当社がマイグレーションで行った、すべての設計および実装の決定を動かすこととなりました。 当社が共有応答性モデルに移行するにあたって、複数の重要な点が浮上しました。第一に、当社のデータ摂取の新しい方法はWootの技術組織にとっては主要な文化シフトでした。過去に、データ摂取は専らデータウェアハウスチームの担当で、サービスからデータを引っ張るためにカスタム化されたパイプラインが必要でした。当社は「押し、引かない」にシフトしました：サーバーがデータウェアハウスにデータを送信するべきである。 これが共有責任が行き着いたところでした。初めて、当社の開発チームがデータウェアハウスのサービスデータ全体の所有権を持ちました。しかし、当社は開発者にミニデータエンジニアになってほしくありませんでした。代わりに、当社はデータをプッシュするために、彼らに開発者の既存のスキルセットに適合する簡単な方法を示しました。データは当社のウェブサイトで使用される技術の範囲でアクセス可能である必要がありました。 これらの検討されたことは当社をサーバーレスデータウェアハウス向けの、以下のAWSサービスを選択することに導きました。 データ摂取用Amazon Kinesis Data Firehose データ保存用Amazon S3 データ処理用AWS Lambda および AWS Glue AWS データマイグレーションサービス (AWS DMS) および データマイグレーション用AWS Glue 統合およびメタデータ管理用AWS Glue クエリおよびデータ視覚化用 Amazon Athena および Amazon QuickSight 以下のデータグラムは当社がどのようにこれらのサービスを使用するかをハイレベルで示します。 トレードオフ これらの構成要素は共に当社のすべての要件を満たし、共有責任モデルを実行可能にしました。しかし、当社はリフト＆シフトマイグレーションをもう一つの関係データベースと比較し、数回のトレードオフを行いました。 最大のトレードオフは先行投資の努力対進行中のメンテナンスでした。当社はすべてのデータパイプラインをもって効果的に白紙の状態から開始し、新しい技術を当社のすべてのウェブサイトサービスに導入しました。これには複数のチームを渡り協力的な努力が必要となりました。最小限の現行メンテナンスは核心要件でした。当社が使用するサーバーレスコンポーネントの管理されたインフラストラクチャーの優位点を利用するために、当社は快くこのトレードオフを行いました。 もう一つのトレードオフは非技術ユーザー対ビッグデータテクノロジーを利用することの有用性のバランスを取ることでした。顧客体験を核心要件にすることは、当社がこれらのトレードオフを検討するときに、意思決定を導くのを助けました。最終的には、他の関係データベースへの切り替えは、当社のお客様が同じ体験をするだけで、より良い体験をするわけではなかったのです。 Kinesis Data Firehose および […]

このブログ記事では、リソースをひとつ、または複数のタグに基づいてグループ化し、スケーリングプランを使用することによって AWS Auto Scaling ポリシーを集約、設定、および管理する方法をご紹介します。スケーリングプランを使用すると、タグを用いることによって AWS Auto Scaling ポリシーの作成を自動化し、これらのポリシーを簡単に変更できます。

AWS Systems Manager Automation は AWS リソースを集中管理するためにマルチアカウントおよびマルチリージョンを対象としたアクションを実行することができます。この機能を活用することでアカウント全体への設定の適用、運用アクション、コンプライアンス管理、に必要な時間とオーバーヘッドを減らすことができます。 このブログ記事では、AWS Systems Manager Automation を使用して、マルチアカウントおよびマルチリージョン環境のマネージドインスタンスにパッチを適用する方法を紹介します。またパッチ適用のために、インスタンス管理にどのようにリソースグループを活用するか説明します。例えば、開発、テスト、および本番などのさまざまな環境用のリソースグループを作成できます。そして Patch Manager を活用したカスタム自動化ドキュメントの作成方法と、カスタム自動化ドキュメントを実行してマネージドインスタンスにパッチを適用する方法を説明します。

この記事では、私たちが 2018 年に掲載した AWS データブログ記事で、最もよく読まれた10本を紹介しています。このリストをガイドとして使って、まだ読んでいないデータベースブログに目を通す、または特に有益だと思った記事を読み返すことができます。

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング エバンジェリストの亀田です。 Kubernetes のマネージドサービスである、Amazon Elastic Container Service for Kubernetes (Amazon EKS)  が東京リージョンに対応しましたのでお知らせいたします。 Amazon EKS では Kubernetes 管理インフラストラクチャ（コントロールプレーン）が複数の AWS アベイラビリティーゾーンで運用されるため、単一障害点をデータセンター単位で排除することができ、高い可用性を実現します。アップストリームの Kubernetes が実行され、Kubernetes への準拠が認証されているため、Amazon EKS で管理されるアプリケーションには、あらゆる標準的な Kubernetes 環境で管理されるアプリケーションとの完全な互換性があります。 また、Amazon EKS は AWS Cloud Mapと統合されています。AWS Cloud Map は動的に変化するインフラストラクチャーが抱える課題である、サービスの自動検出機能を提供します。アプリケーションリソースのカスタム名を定義し、これらの動的に変化するリソースの更新された場所を管理できます。これにより、Webサービスが常にリソースの最新の場所を検出するため、アプリケーションの可用性が向上します。 また、Application Load Balancer とも  AWS ALB Ingress controller を介して連携することが可能です。Application Load Balancer は先日 Lambda対応も発表され、アプリケーション内部において、それぞれの目的に合致したパスベースルーティングを可能とします。 料金はこちらにまとまっています。 – プロダクトマーケティング エバンジェリスト 亀田 […]

前回の記事では、Ben Snively と Vai Desai が、サーバーレス技術を用いてソーシャルメディアのダッシュボードを構築する方法を紹介しました。ソーシャルメディアのダッシュボードは「#AWS」のハッシュタグでツイートを読み取り、機械学習ベースのサービスを使用して翻訳を行い、自然言語処理 (NLP) を使用してトピック、エンティティ、センチメント分析を行います。最後に、Amazon Athena を使用してこの情報を集計し、ダッシュボードを作成して、ツイートから取得した情報を可視化します。このアーキテクチャでは、管理する唯一のサーバーは Twitter フィードを読み取るアプリケーションを実行します。このブログ記事では、このアプリケーションを Docker コンテナに移動し、AWS Fargate を使用して Amazon ECS で実行する手順について説明します。これにより、アーキテクチャ内で Amazon EC2 インスタンスを管理する必要がなくなります。 AWS Fargate は、Amazon Elastic Container Service (ECS) のテクノロジーで、それによりサーバーやクラスターを管理することなくコンテナを実行できるようになります。AWS Fargate を使用すると、コンテナを実行するために仮想マシンのクラスタをプロビジョニング、構成、および拡張する必要がなくなります。これにより、サーバーの種類を選択したり、クラスターをいつスケールするかを決めたり、クラスターのパッキングを最適化したりする必要がなくなります。AWS Fargate により、サーバーやクラスターとやり取りしたり、考えたりする必要がなくなります。AWS Fargate を使用すると、コンテナアプリケーションを実行するインフラストラクチャを管理する代わりに、コンテナアプリケーションの設計と構築に専念できます。 AWS Fargate は、Amazon EC2 の運用上の責任を排除したい場合に最適です。AWS Fargate は、AWS CodeStar、AWS CodeBuild、AWS CodeDeploy、AWS CodePipeline などの AWS Code サービスと完全に統合されており、エンドツーエンドの継続的な配信パイプラインを設定して ECS への導入を自動化することが難なく行えます。 Fargate でツイート読み取りアプリを実行する […]

イントロダクション Amazon CloudWatchイベントは、AWSリソースのタグ変更をサポートするようになりました。この新しいCloudWatchイベントタイプを使用すると、タグ変更に適合するCloudWatchイベントルールを作成でき、AWS Lambda関数など複数のターゲットにルーティングすることで、ワークフローを自動で開始することができます。このブログ記事では、AWSリソースに対するタグ変更をセキュアに実施するための、AWS Lambdaを使用したコスト効率の高いサーバーレスソリューションを構築する例を示します。

本日より、アプリケーション ロードバランサー (ALB)はAWS Lambda functionをターゲットにすることをサポートします。ウェブサイトの構築やウェブアプリケーションをAWS Lambdaを使いサーバレスなコードとして作成、管理し、ウェブブラウザやクライアントからのリクエストに簡単なHTTP(S)フロントエンドを提供するように設定できます。

AWS App Meshは、AWS上のマイクロサービスアプリケーション間の通信を簡単に監視、制御できるサービスメッシュです。 Amazon Elastic Container Service (Amazon ECS)やAmazon Elastic Container Service for Kubernetes (Amazon EKS)、Amazon EC2上で稼働するKubernetesで動作するマイクロサービスとあわせてApp Meshを使用できます。 今日からApp Meshはpublic previewとして利用できます。数ヶ月後に、新しい機能とインテグレーションを追加する計画です。 なぜApp Meshなのか？ 多くのお客様はマイクロサービスアーキテクチャでアプリケーションを構成しており、アプリケーションを多数の、独立してデプロイされ、操作される多数の別々の小さなソフトウエア群に分割しています。各コンポーネントが需要に応じて個別にスケールすることにより、マイクロサービスはアプリケーションの可用性とスケーラビリティを向上させます。各マイクロサービスはAPIを通じて他のマイクロサービスと相互に作用します。

ソフトウェア開発者には好みの開発ツールというものがあります。パワフルなエディタを使う人もいれば、特定の言語やプラットフォームに最適化された統合開発環境（IDE）を使う人もいます。AWS Lambda のコンソールのエディタを使って、2014年に私は初めての AWS Lambda 関数を作りました。現在では、サーバーレス・アプリケーションをビルドしデプロイするためのツールの選択肢は豊富になりました。例えば、昨年 AWS Cloud9 がリリースされて AWS Lambda のコンソールのエディタ環境は大きく強化されました。.NET アプリケーションでは、 AWS Toolkit for Visual Studio と AWS Tools for Visual Studio Team Services を使う事ができます。 AWS Toolkits for PyCharm、IntelliJ（プレビュー）、そして Visual Studio Code（プレビュー） 今日、 AWS Toolkit for PyCharm の一般提供をお知らせします。また、 AWS Toolkits for IntelliJ と Visual Studio Code の開発者プレビューをお知らせします。これら（AWS Toolkits for IntelliJ と Visual Studio […]