Category: General

こんにちは、マーケティングの鬼形です。 先日 (2018/4/4) 開催致しました AWS Black Belt Online Seminar「Amazon Macie」の資料を公開いたしました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

こんにちは、ソリューションアーキテクトの江原です。 先日(2018/3/27)開催致しました AWS Black Belt Online Seminar「AWS IoTでのデバイス管理、運用について」の資料を公開いたしました。当日、参加者の皆様から頂いた QA の回答と併せてご紹介致します。

Felipe Garcia と Hugo Rozestraten は  Amazon Web Services の  Solutions Architect です。 この記事では、実際のお客様の事例をもとに、Amazon Redshift の前段に pgpool と Amazon ElastiCache を使ってキャシングレイヤを構築する方法を紹介します（訳注：原文執筆時にはRedshiftにキャッシュ搭載されていなかったのですが、現在はRedshiftには結果キャッシュの機能が備わっているため、キャッシュするだけのためにこのようなソリューションを作成する必要はありません。しかしpgpoolはキャッシュ以外にも利用できる柔軟なソリューションであり、それを分かりやすく示している資料として価値があるため、翻訳記事を掲載しています） 近年、業務アプリケーションはほとんどの場合データベースの利用を想定して構築されます。SQLによるデータベースへのクエリは広く普及した技術ですが、エンドユーザとアプリケーション間の協調を意識しないアーキテクチャ設計が、まったく同一のクエリの複数回実行といった無駄な処理を時として発生させます。このような冗長な処理は計算資源の無駄遣いであり、こういった無駄を省くことができれば他の処理に計算資源を有効活用することができるようになります。 キャッシュとは コンピュータ用語としてのキャッシュは、将来発生し得るリクエストに迅速に回答するためにデータを事前に蓄積しておくハードウェアコンポーネントまたはソフトウェアコンポーネントを指します。また、必要なデータがキャッシュの中に見つかることをキャッシュヒットといい、必要なデータがキャッシュの中に存在しないことをキャッシュミスといいます。キャッシュの存在により、重い計算の再実行や遅いデータストアからの読み出しが発生しなくなり、高速に結果を得られるようになります。より多くの要求がキャッシュで処理できれば、システムはより高いパフォーマンスを発揮することができます。 お客様事例：臨床研究での遺伝子情報の検索 この事例では、6-10名程度からなる科学者のチームが200万からなる遺伝子のコードの中から特定の遺伝子変異を探し出します。特定の遺伝子変異に隣接する遺伝子も重要な遺伝子で、これらにより異常や病気などが特定できるようになります。 科学者たちは、1つのDNAサンプルをチームで同時に解析し、その後ミーティングを開き自分たちの発見について議論し、結論へと到達します。 この事例では、Node.js のウェブアプリケーションにロジックを実装し、Amazon Redshift にクエリを発行しています。Amazon Redshfit に直接接続したアプリケーションでは、クエリのレイテンシは約10秒でした。アーキテクチャを変更しpgpoolを使用するようにしたところキャッシュにヒットした際に1秒未満で同一のクエリの結果を得られるようになりました。(言い換えると、キャッシュヒット時に10倍高速に応答できるようになりました。)　（訳注：現時点ではRedshiftに結果キャッシュの機能が存在するため、こういった仕組み無しでもキャッシュヒット時に高速な応答が実現されています） Pgpoolの紹介 Pgpool はデータベース・クライアントとデータベース・サーバの間で動作するソフトウェアです。リバースプロキシとして動作し、クライアントからの接続要求を受け、サーバへとそれをフォワードします。もともと PostgreSQL のために書かれており、キャッシング以外にも、コネクションプーリング、レプリケーション、ロードバランシング、コネクションキューイングといった機能を備えます。本稿では、キャッシング機能のみを検証しています。 Pgpool は、Amazon EC2 上でも、オンプレミス環境でも動作させることができます。たとえば、開発やテスト目的でEC2のシングル構成をとるこもできますし、本番環境のために Elastic Load Balancing 、Auto Scaling 構成のEC2複数台構成をとることもできます。 臨床研究の事例では、psql(コマンドライン)と Node.js アプリケーションから Amazon Redshift に対してクエリを発行していて、実際に期待通りに動作することが確認できています。ご自身の環境に適用する場合には、十分な検証を経た上での採用をおすすめいたします。   […]

こんにちは、ソリューションアーキテクトの有岡です。 先日(2018/3/19)開催致しました AWS Black Belt Online Seminar「データウェアハウスのAWSへの移行」の資料を公開いたしました。当日、参加者の皆様から頂いた QA の回答と併せてご紹介致します。

Amazon DynamoDBチームはencryption at restに引き続き新しい機能を発表しました。AWS re:Invent 2017 では、グローバルテーブルの作成と DynamoDBテーブルのオンデマンドバックアップとリストアを発表しました。そして今日、継続的バックアップとしてPITR（ポイントインタイムリカバリ）を利用出来るようになりました。 AWS Management Consoleからワンクリックするか、簡単なAPIコール、またはAWSコマンドラインインターフェイス（CLI）を使用して継続的バックアップを有効にすることができます。DynamoDBはPITRが有効になってから35日以内であれば1秒単位でデータをバックアップし、1秒単位でリストアできます。誤った書き込みや削除を防ぐためにこの機能を構築しました。開発者がステージングではなくプロダクションに対してスクリプトを実行した場合や誤ったDeleteItemを実行した場合はPITRでカバー出来ます。その為予測できないようなシナリオにも利用出来ます。オンデマンドバックアップはアーカイブ目的のために必要なタイミングを指定できますが、PITRは偶発的なデータ消失に対する追加の保険として機能します。これがどのように機能するか見てみましょう。 継続的バックアップ マネジメントコンソールでこの機能を有効にするには、テーブルに移動して[ バックアップ ]タブを選択します。そこから、Enableをクリックするだけで有効になります。また、UpdateContinuousBackups API呼び出しを使用して継続的バックアップを有効にすることもできます。 継続的バックアップを有効にした後、最も遠い復元日と最新の復元日時を確認出来ます。 削除したい古いユーザーデータがたくさんある、というシナリオを例にとってみます。 私はlast_updateに格納されている日付に基づいてアクティブなユーザーだけに通知を送信したいと考えました。そしてサービスを使用していないユーザーを削除するために簡単なPythonスクリプトを書くことに決めました。 import boto3 table = boto3.resource(“dynamodb”).Table(“VerySuperImportantTable”) items = table.scan( FilterExpression=”last_update >= :date”, ExpressionAttributeValues={“:date”: “2014-01-01T00:00:00″}, ProjectionExpression=”ImportantId” )[‘Items’] print(“Deleting {} Items! Dangerous.”.format(len(items))) with table.batch_writer() as batch: for item in items: batch.delete_item(Key=item) すばらしい！これでサービスに2013年以来ログインしていない厄介な非アクティブユーザをすべて削除するはず・・・CTRL + C CTRL + C CTRL + […]

みなさん、こんにちわ。プロダクトマーケティング エバンジェリストの亀田です。 AWSomeDayというイベントとをご存知でしょうか。 AWSの有償トレーニングコースである [AWS Technical Essentials 1] [AWS Technical Essentials 2] について、お申込み自由で、1日座学にてAWSの基礎を学んでいただくイベントです。講師は通常、有償トレーニングコースを担当しているテクニカルインストラクターや私がQ&Aを含めて担当させていただいています。 4/3に大阪、4/17にオンラインでも開催が予定されており、AWSomeDayはこのほかにも、AWSomeDay for Partnerのようにパートナー向けイベントも定期開催されています。 2019年に追加で新規立ち上げの開催が予定されているAWSomeday for Academyのトライアルを先日「 船橋情報ビジネス専門学校」の協力を経て実施いたしました。 サーバーやデータセンターなどに馴染みのない方々に、わかりやすくクラウドのパワーを体験いただくために、いろいろな比喩などを交えながら説明を行うことに、テクニカルインストラクターや私も頭をひねりながら楽しみました。 学校らしく授業の最初は「起立、礼、着席」で始まり学校の先生気分です。                             （生徒さんの許可を得て撮影させてもらいました）                               学生さんは授業に慣れているので、講師からの質問にも多くの手が上がり会場は盛り上がっています。     […]

みなさん、こんにちわ。プロダクトマーケティング エバンジェリストの亀田です。今日はみなさんのクラウド移行プロジェクトに役に立つクラウド移行支援プログラム、Migration Acceleration Program (通称MAP)についてご紹介をいたします。 こちらのウェブサイトはまだ英語ですが、日本でもご利用可能なプログラムで大規模なシステム移行プロジェクトを支援するものとなっています。 企業の中ですでに稼働しているITリソースをクラウドへ移行させるためのきっかけは多くのパターンが存在し、お客様毎にその事情は異なります。                 一方システムをクラウドへ移行させるには以下4つのプロセスを経ることが一般的です。 １．個別プロジェクトで小規模なシステムなどでクラウドを使い始めるステージ このステージでは、AWSでは通常ミッションクリティカルなシステムではなく、関係者や連携するシステムが少ないワークロードを選定しクラウドを使い始めることをお勧めしています。そうして、複数のプロジェクトを経験する中で、知見をためていくことになります。 ２．ハイブリッド化のステージ ステージ１である程度の知見が蓄積され手法が確立され、移行対象システムの規模及び範囲が拡大されていきます。一度のすべてのシステム移行は時間がかかるため、システムはオンプレミスとクラウドのハイブリッド化するケースがあります。この時点でAWS Direct Connectの敷設などが実施されるケースも多く存在しています。Direct Connectは専用線による通信によりクラウドとのデータのやり取りをセキュアにする機能の他に、企業ネットワークからクラウドへの通信において安定した帯域を安価に確保する側面も存在しています。 ３．大規模移行のステージ ハイブリッド化のシステムのクラウド全面移行や、ERP等基幹系ミッションクリティカルシステムのクラウドマイグレーション等が行われるステージです。Migration Acceleration Program (通称MAP) は主にこのフェーズをターゲットとして適応可能なプログラムになっています。 ４．クラウド最適化のステージ クラウド上で稼働しているシステムアーキテクチャーの変更を、よりクラウドに適した形態に変更していくステージです。これによりクラウドの利用料はより最適化され、耐障害性や可用性なども併せて最適化されていきます。 企業がこういうステップを踏んでITリソースをクラウドへ移行させるプロセスを、AWSでは「クラウドジャーニー」と呼んでいます。このクラウドジャーニーにおいて同時に整備が必要なものが図の右側にある人的リソース関連になります。 これらをすべて自社で賄うには難しいケースがあります。特に、エンジニアのトレーニングやクラウドマイグレーションの実行計画作成、現状とのフィットアンドギャップ作成、各種試算に役立つツールのご提供などがそれにあたり、それらをお手伝いする、プログラムがMAPです。 –    移行をするかどうかまだ検討中の場合は Rapid Opportunity Calculator というツールをご提供しています。 –    　移行を決められててInfraの移行コストをアセスメントする場合は TCO Calculator　をご利用いただくことができます。どなたでもアクセス可能です。 –    クラウド移行を前提とした、詳細のインフラストラクチャー/アプリケーション/ システムの生産性/財務状況などを含むMigration Business Caseの作成 AWS プロフェッショナルサービスもしくは弊社Partnerが作業をお手伝いいたしますのでお声がけください。 2006年のサービス提供開始以降、10年以上にわたりお客様と共に行った多くのプロジェクト経験で得たノウハウを、文書化やフレームワーク化を行い皆様にご提供差し上げ、また各種試算にご利用いただける用にご提供差し上げるツールも活用しながら、ともにクラウド移行を推進していくプログラムとなっています。 MAPプログラムでは、将来的なAWSのご利用料予測をもとに、AWSご利用料クレジットを一定割合付与させていただける特典もついております。AWSご利用料予測が、移行後の規模において$1M/年以上想定される場合、ぜひお声がけください。 また、MAP以外にもお客様のクラウドジャーニーをお手伝いする、トレーニング、プロフェッショナルサービス、24時間日本語対応が可能なサポートサービス、等もご提供しています。 – プロダクトマーケティング エバンジェリスト 亀田 […]

オンプレミスのユーザー管理者が、AWS Managed Microsoft ADとも呼ばれる “AWS Directory Service for Microsoft Active Directory” を管理できるようになりました。 Active Directory（AD）信頼と新しいAWS委任ADセキュリティグループを使用すると、オンプレミスADディレクトリのグループメンバシップを管理することで、オンプレミスユーザーに管理アクセス許可を与えることができます。これにより、管理を実行できるユーザーを簡単に管理できます。また、管理者は、オンプレミスのAD資格情報を使用して既存のワークステーションにサインインして、AWS Managed Microsoft ADを管理できるため、管理者の作業が楽になります。 AWSは、AWS Managed Microsoft ADディレクトリに新しいドメインローカルADセキュリティグループ（AWS委任グループ）を作成しました。各AWS委任グループには、一意のAD管理者権限があります。新しいAWS委任グループのメンバーであるユーザーは、ユーザーの追加、細かいパスワードポリシーの構成、Microsoftエンタープライズ認証局の有効化などの管理タスクを実行するためのアクセス許可を取得します。 AWS委任されたグループは、範囲内のドメインローカルなので、オンプレミスADに対するAD信頼を使用してそれらを使用できます。これにより、AWS Managed Microsoft ADを管理するために別個のIDを作成して使用する必要がなくなります。代わりに、選択したオンプレミスユーザーを必要なAWS委任グループに追加することで、管理者に権限の一部またはすべてを付与できます。オンプレミスのADセキュリティグループをAWS委任グループに追加することで、これをさらに簡素化できます。これにより、オンプレミスのADセキュリティグループからユーザーを追加したり削除したりして、AWS Managed Microsoft ADの管理者権限を管理できるようになります。 このブログでは、オンプレミスのユーザーに権限を委任して、管理タスク（AWS Managed Microsoft ADディレクトリの細かなパスワードポリシーの設定）を実行する方法を説明します。この記事の手順に従うことで、グループマネージドサービスアカウントとKerberos制約付き委任の構成などの他の管理アクセス許可をオンプレミスのユーザーに委任できます。   背景 これまで、AWS Managed Microsoft ADは、組織単位（OU）にADセキュリティグループを作成し、これらのAWS委任グループに共通管理アクティビティを許可することによって、ディレクトリの管理者権限を委任していました。ディレクトリ内の管理者ユーザーは、OU内にユーザーアカウントを作成し、これらのユーザーにこれらのAWS委任グループの1つ以上にディレクトリを追加してディレクトリを管理する権限を与えていました。 ただし、オンプレミスADフォレストへの信頼をAWS Managed Microsoft ADに構成した場合、オンプレミスディレクトリのユーザーをこれらのAWS委任グループに追加することはできませんでした。これは、AWSがグローバルスコープのAWS委任グループを作成し、別のフォレストからのユーザーの追加を制限するためです。そのため、管理目的でAWS Managed Microsoft ADに異なるユーザーアカウントを作成する必要がありました。その結果、AD管理者は、通常、AWS Managed Microsoft ADの追加の資格情報を覚えておく必要がありました。 これに対処するために、AWSはドメインローカルスコープを持つ新しいAWS委任グループを、AWS Delegated Groupsと呼ばれる別個のOUに作成しました。ドメインローカルスコープを持つこれらの新しいAWS委任グループは柔軟性が高く、他のドメインやフォレストからのユーザーやグループの追加を可能にします。これにより、管理者ユーザは社内のユーザおよびグループの管理者権限をAWS Managed Microsoft ADディレクトリに委任できます。 備考: […]

みなさん、こんにちわ。プロダクトマーケティング エバンジェリストの亀田です。 3月10日に五反田で開催されたJAWS DAYS 2018において、Keynoteの「AWS Technical Evangelists Special talk session -スペシャルトークセッション AWSとユーザーコミュニティが生み出すNo borderな未来-」について、非常に含蓄の多い話が多かったため、当日の流れを以下に記載します。 JAWS DAYS 2018ではコミュニティメンバーを中心にAWSでも、海外から多くのゲストが訪れていました。 パネルセッションはAWSエバンジェリストの以下4名とモデレーターの私で行いました。 – Jeff Bar                       – Randall Hunt                       – Julio Faerman               […]

こんにちは、ソリューションアーキテクトの石井です。 先日(2018/3/08)開催致しました AWS Black Belt Online Seminar 「Amazon SageMaker」の資料を公開いたしました。当日参加者の皆様から頂いたQAの回答と併せてご紹介致します。