Amazon Web Services ブログ

AWS Japan

Author: AWS Japan

クライアントデバイスからのポート443でのTLSクライアント認証によるMQTTの実装方法(Python)

アプリケーション レイヤ プロトコル ネゴシエーション(Application Layer Negotiation:ALPN)は、TLSの拡張機能として、TLSサーバに接続しているクライアントがProtocolNameListという追加パラメータを渡すことを可能とします。ProtocolNameListは、クライアントが通信に使用したいアプリケーションプロトコルの優先順位付きリストです。 AWS IoT Coreでは、ALPN TLS extensionを使用して、ポート443でTLSクライアント認証を使用してMQTT経由でデバイスを接続できるようになりました。なぜこれが便利なのかについては、このブログ記事を参照してください。

Read More

[AWS White Belt Online Seminar] クラウドジャーニー (AWSへの移行プロセスと移行ツール) 資料及び QA 公開

こんにちは、マーケティングの鬼形です。 先日 (2018/4/17) 開催しました AWS White Belt Online Seminar「クラウドジャーニー (AWSへの移行プロセスと移行ツール)」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

Read More

【開催報告】第12回 AWS Startup Tech Meetup

こんにちは、スタートアップ担当SAマネージャーの篠原英治(@shinodogg)です。 AWSをご利用中のStartup企業で働くエンジニアのコミュニティであるAWS Startup Tech Communityで、先日12回目のMeetupをAmazon目黒オフィスで開催しました。今回も実践的な発表が多く、カジュアルな雰囲気の中でも深い内容になりました。 今回、写真はSORACOMのエンジニア山下さんに撮っていただきました! – カウルを支える技術の作り方: Housmart 高松智明さん 中古マンションの購入を検討している方であれば一度は見たことがカウル。HousmartのCTOとして技術選定を行ってきた高松さん。 機械学習技術やその為のGPUインスタンスの活用など、参考になるお話をありがとうございました! – Under the Hood of SORACOM: ソラコム 松本悠輔さん 会場の挙手アンケートで知らない人がいない存在のソラコムのソリューションアーキテクトの松本さんからSORACOMの裏側のお話をしていただきました。 SORACOMがいかにシンプルさと拡張性を高く保っているかが垣間見えるようなステキなお話でしたし、Q&Aの時間ではサポートエンジニアの山下さんからもご回答いただきました。写真撮影に質問の回答に、と多大なご協力をいただきましてありがとうございました! – aperzaを支える技術: アペルザ 山崎篤史さん aperzaを支える技術 製造業にまつわる膨大なデータを整理していく上でのクローラーやデータストアなどについてアペルザで取り組んでいることを構成図を交えてご紹介してくれました。 – Kubernetes 入門者が 3 か月で本番導入するためにやったこと: freee 坂井学さん Kubernetes 入門者が 3 か月で本番導入するためにやったこと / kubernetes-beginner 本番環境でDockerを使うのもはじめての状態から、Kubernetesを導入までもっていったfreeeのSRE坂井さんからは、新しい技術を導入する上でのメンタル面も含めた実践的なお話をしていただきました。 – AWS Summit Tokyo 2018の楽しみ方: AWS 塚田朗弘 来るAWS Summit TokyoではAWS JapanのStartupチーム総出で様々なアクティビティを予定していますが、AWSのStartup担当SAの塚田からStartup Architecture of the year […]

Read More

[AWS Black Belt Online Seminar] AWS で構築するデータレイク基盤のアーキテクチャ 資料及び QA 公開

こんにちは、マーケティングの鬼形です。 先日(2018/4/24)開催しました AWS Black Belt Online Seminar「AWS で構築するデータレイク基盤のアーキテクチャ」の資料を公開致しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

Read More

AWS Developer Toolsを使用したサーバレスなAWS Glue ETLアプリケーションの継続的インテグレーションとデリバリの実装

大規模なデータおよびデータレイクのワークロード用にサーバーレスETL(抽出、変換およびロード)アプリケーションを開発するためにAWS Glueはますます普及しています。 ETLアプリケーションをクラウドベースのサーバーレスETLアーキテクチャに変換する組織は、ソースコードからビルド、デプロイ、プロダクトデリバリまで、シームレスでエンドツーエンドの継続的なインテグレーションおよび継続的なデリバリ(CI / CD)パイプラインが必要です。優れたCI / CDパイプラインを持つことで、組織はプロダクションリリース前にバグを発見し、より頻繁にアップデートを提供することができます。また、開発者が高品質のコードを書いたり、ETLのジョブリリース管理プロセスを自動化したり、リスクを軽減したりするのに役立ちます。 AWS Glueは、フルマネージドのデータカタログとETLのサービスです。これは、データの発見、変換、およびジョブスケジューリングなどの困難で時間のかかる作業を簡素化し自動化します。 AWS Glueは、データソースをクロールし、CSV、Apache Parquet、JSONなどの一般的なデータフォーマットとデータタイプ用に事前に作成された分類子を使用してデータカタログを構築します。 AWS Glueを使用してETLアプリケーションを開発する場合、CI / CDの次のような課題に直面する場合があります。 ユニットテストによる繰り返しの開発 継続的なインテグレーションとビルド ETLパイプラインをテスト環境にプッシュする ETLパイプラインをプロダクション環境にプッシュする 実データを使用したETLアプリケーションのテスト(live test) データの調査と検証 この記事では、AWS Developer Tools(AWS CodePipeline、AWS CodeCommit、AWS CodeBuildなど)とAWS CloudFormationがサポートするサーバーレスAWS Glue ETLアプリケーションのCI / CDパイプラインを実装するソリューションを紹介します。 ソリューションの概要 次の図は、ワークフローのパイプラインを示しています。 このソリューションでは、AWS CodePipelineを使用して、ETLアプリケーションのソースコードのテストおよびステージへのデプロイを制御および自動化することができます。 このソリューションは、以下のステージを含むパイプラインで構成されています。 1.)Source Control:このステージでは、デプロイするETLジョブのAWS Glue ETLジョブソースコードとAWS CloudFormationテンプレートファイルの両方がバージョン管理にコミットされます。 バージョン管理にAWS CodeCommitを使用することにしました。 ETLジョブソースコードとAWS CloudFormationテンプレートを取得するには、gluedemoetl.zipファイルをダウンロードします。 このソリューションは、以前の記事、AWS Glue と Amazon S3 を使用してデータレイクの基礎を構築するに基づいて開発されました。 2.)LiveTest:このステージでは、AWS […]

Read More

[AWS Black Belt Online Seminar] Amazon VPC 資料及び QA 公開

こんにちは、マーケティングの鬼形です。 先日(2018/4/18) 開催された AWS Black Belt Online Seminar「Amazon VPC」の資料を公開いたしました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20180418 AWS Black Belt Online Seminar Amazon VPC PDF 録画(オンデマンドセミナー) Q1. (自己紹介の質問) Market Place の何が好きか教えていただけるとうれしいです。 A. Network 担当ということで、様々なルータやファイアーウォール製品を時間単位で複数お試しができるので、検証が簡単にできるのが好きなところです。 Q2. 別々の VPC では物理的にネットワークが分離する認識で合っていますか。 A. 別々の VPC は論理的にネットワークが分離されます。 Q3. VPC を分ける単位のベストプラクティスはありますでしょうか。 A. ページ 76,77 でいくつか例をご紹介させていただきました。よりよいベストプラクティスをお探しの場合は是非 Well-Architectedをご参照ください。 Q4. 異なるリージョンのAZを、1つのリージョンから指定することはできますか。 A. リージョンの内部にアベイラビリティゾーン(AZ)が存在するので、指定することはできません。それぞれのリージョンから AZ を選択してください。 Q5. (サブネット作成時の)ネームタグの命名規則について推奨はありますか。 A. 特に推奨はありませんが、わかりやすいように私は […]

Read More

MySQLデータベースをAuroraへ移行する方法をマスターする

By Nathaniel Kangpan, SVP Technology & Data Services, Kepler Group 私は過去12ヶ月の間に(a)クラウドベースのインフラストラクチャを使うことに踏み出していない、もしくはその様なチームがいない(b)2018年のロードマップにクラウドを使うことが乗っていないクライアントに会っていません。ハードウェアからクラウドへ移行した場合のTotal Cost of Ownership(TCO)の節約は無視できません。 しかし、所有しているハードウェアからAWSのようなクラウドベースのインフラストラクチャに移行する際には、本当に何を期待するべきですか? Amazon EC2などの仮想サーバー上にソリューションを複製するだけでいいですか、Amazon RDSのようなマネージドサービスを増やすべきででしょうか? Kepler Groupでは、インフラストラクチャの95%以上が2014年後半からAWS上で稼働しています。過去数年にわたり、多くのお客様に機転となる時に何を期待しているかをアドバイスしました。私達はマーケティングデータベース管理サービスを提供しています。クライアントとの最も一般的な議論の1つは、リレーショナルデータベースをAWSに移行する際に抱えるメリットと課題を理解する助けとなることです。   Global Fortune 100の例 私たちは通常、Global Fortune 100クライアントのために完成した代表的なプロジェクトを中心に、データベースクラウドの移行に関する会話行っています。この特定のクライアントにとって、私たちは最初に、データセンターのハードウェア上にMySQLデータベースを構築しました。その後、MySQLを実行しているEC2インスタンスに移行し、最終的にAmazon Aurora MySQLに移行をしました。クライアントのユースケースと基本的なデータスキーマは、この間にあまり変化しませんでした。そのため、私たちはソリューションの管理がますます効率化されるようになるにつれ、同じMySQLデータベースを複数のフレームワークで実行することの長所と短所について多くのことを学びました。 今回の対象のデータベースは、マーケティングおよびセールスカスタマーリレーションシップマネジメント(CRM)データベースでした。一連の電子メールおよびセールスチームベースのマーケティングキャンペーンで、レポートおよび分析ユースケースのために複数のサードパーティソースにデータを継続的に集約しました。私たちのチームは、データベースの管理に加え、マネージドサービスとしてレポートと分析の提供を担当する主なユーザーです。 このプロジェクトは、スコープと予算の面で一般的に管理していた物の小規模なものでした。クライアントのニーズを満たすことに加えて、次の点に細心の注意を払う必要がありました: データベースメンテナンスの負荷を低く抑える インフラストラクチャコストの制限 信頼性の高いバックアップおよびリカバリプロセスを確保する 前述のように、データベース用に3つの異なるインフラストラクチャソリューションを使い、各バージョンのメリットと課題についてかなりのことを学びました: v1.0:オンプレミスハードウェア上のLinuxでMySQLを実行する v2.0:Amazon EC2上のLinuxでMySQLを実行する v3.0:MySQLと互換性を持つAmazon Aurora 次の移行の概要では、各バージョンへの移行の決定と、その過程で得た利点と課題について説明します。   Version 1.0: オンプレミスハードウェア上のLinuxでMySQLを実行する 2013年後半にこのクライアントとの関係を開始したとき、クラウドベースのサービスを検討し始めましたが、私たちのインフラストラクチャは、データセンターを基盤とするハードウェアソリューションでした。クライアントサービスや厳しい締め切りで働いている多くの人が理解できるように、理想的な長期的なソリューションを最初から構築するのではなく、迅速に稼働させることを優先する必要がありました。私たちは、オンプレミスハードウェア上のLinuxとMySQLの組み合わせから開始することにしました。これは、このプロジェクトで作業しているエンジニアが最も慣れている構成だったからです。 利点 この初期のアプローチの唯一のメリットは、エンジニアがハードウェア+ Linux + MySQLの構成でよく作業していたことです。必要な開発フレームワーク、データ転送メカニズムなどはすべてかなり理解されており、大きな技術的驚きは期待できませんでした。これにより、限られたAWS経験を持つクラウドベースのソリューションに飛び込むのとは対象的に、納期と予算に対するリスクを最小限に抑えながら顧客の設定した期限を迎えることができるという自信が得られました。 チャレンジ しかし、ハードウェア環境で解決策を維持することには、かなりの数の問題がありました。AWSへの移行を後で行うまでは、これらの非効率性を十分に理解していませんでした。具体的には、クラウドと比較してハードウェアソリューションでは次のような課題に直面しました: かなり高いサーバーとデータベースのメンテナンスとアップグレードの運用負荷 時間の経過とともに増加するデータ量に対応する、シームレスではない垂直スケーリングプロセス […]

Read More

【開催報告】Amazon Chimeを使ったJAWS DAYS 2018 re:Capが開催されました

こんにちは。コミュニティプログラム担当の沼口です。JAWS-UG(Japan AWS User Group)は全国50以上の支部から成り立っており、それぞれの地域で独自に勉強会を企画、開催しています。各支部で勉強会が完結している場合が多いのですが、東京で開催されたJAWS DAYS 2018のre:Cap(参加できなかった人向けに、実際に参加した人がセッション内容を紹介する勉強会)などを地方単独でやるのは、登壇者への負担が大きいという課題がありました。 先日(2018/4/13)、石川県の金沢支部、静岡県の磐田支部、愛知県の名古屋支部の3つの勉強会会場をAWSが提供する統合コミュニケーションサービスの「Amazon Chime」を使い、それぞれの支部からJAWS DAYS 2018 re:Capの登壇者を募り、3元中継で合同勉強会を開催しました。各支部の勉強会会場からChimeを使って、プレゼンテーション画面の共有と音声と映像を配信することで、3名3地域の登壇者によるre:Capプレゼンテーションを実施し、JAWS DAYSで印象に残ったセッションの紹介、参加した感想などを参加メンバーと共有することができました。                     [金沢会場の登壇者によるプレゼンテーション]                   [各支部の模様はWebカメラを通してChimeで確認可能]                   [他支部のプレゼンテーションをプロジェクターで視聴]   Amazon Chimeを使った感想として、映像、音声ともにオンライン中継で使えるレベルである、という高評価をいただきました。一部、会場のスピーカーによっては聞きづらかったケースもありましたが、テレビ会議用のスピーカーフォンを準備したり、PCから会場に設置されている音響機器にケーブル接続したりすることで問題がない、というお墨付きをいただきました。一方、共有画面のウィンドウを間違えてしまった、プレゼンテーション中のポインターの利用方法など、今後ノウハウを蓄積・共有すべき点も明確になってきました。   各支部各地域の熱心なユーザーによる勉強会によって支えられているJAWS-UGですが、地方支部単独開催になるとコアリーダーの負担が大きくなりがちです。AWSは弊社社員による登壇参加などでの勉強会支援もしていますが、このようにAmazon Chimeなどを提供することで、コアリーダーの負担を減らしながら、勉強会を盛り上げていけるよう、さまざまな支援をJAWS-UGに対して提案・実施しています。 オフラインによる勉強会の良さを維持しながらも、オンラインサービスを効果的に使うことで、JAWS-UGの方々の負担を軽減しながらも、楽しく、ためになる勉強会になることを期待しています。来月の5月に開催予定のJAWS-UG勉強会Alexa.Westも同じくAmazon Chimeを使って大阪、神戸、京都、岡山、和歌山をつなげて、5元中継の合同勉強会になる予定です。 JAWS-UG勉強会情報はJAWS-UGのホームページに掲載されているスケジュールか、AWSのホームページの「イベント&オンラインセミナー」の「ユーザーグループ」のセクションで確認できます。ぜひチェックして興味のある勉強会に参加してはいかがでしょうか。   アマゾン ウェブ […]

Read More