Amazon Web Services ブログ

AWS ConfigでSAPシステムを評価する – パート1

はじめに SAP on AWSをご利用のお客様は、SAPシステムの日常運用を強化し単純化できる幅広い追加サービスを利用可能です。よく見かける面倒なタスクの1つとして、SAPシステムがベストプラクティスに従って構成されているかどうかということや、ベンダーサポートの要件を満たしているか、内部監査要件を満たしているかどうか、という点があります。 このブログシリーズでは、AWS Configがお客様のランドスケープ内の全てのSAPシステムのコンプライアンスを継続的に監査および評価するプロセスを簡素化する方法についてご説明します。また、Amazon Event BridgeおよびAmazon Simple Notification Serviceを使用して、リソースが非準拠として識別された場合にEメール通知を有効にする追加手順をお届けします。

Read More

新しい Amazon EKS コンソールの紹介

この記事は、Introducing the new Amazon EKS console を翻訳したものです。 Amazon Elastic Kubernetes Service (EKS) は re:Invent 2017 にて提供を開始して以来、 Kubernetes を本番環境で利用するユーザーのニーズを満たすように急速に進化してきました。Intel、Snap、Intuit、GoDaddy、Autodesk などのお客様は、セキュリティ、信頼性、およびスケーラビリティの高さを理由に、最も機密性の高いミッションクリティカルなアプリケーションをAmazon EKS 上で実行しています。 Amazon EKS には、Kubernetes のアプリケーションや API リソースの設定を簡単に可視化できるシンプルな方法がありませんでした。問題を特定して調査するには、Kubernetes と AWS 全体を手動で追跡する必要がありました。これらの作業はすべて、特に新しいユーザーにとって、Amazon EKS を始めて、実行するのに多くの時間が必要なものでした。 2020年12月1日、我々は新しい Amazon EKS コンソールを発表できることを嬉しく思います。Amazon EKS では、Kubernetes クラスター、アプリケーション、および関連するクラウドリソースのステータスを単一の場所で確認できます。新しいコンソールを使うことで、お客様は Kubernetes 環境にまつわる情報をすぐに手に入れられるようになり、アプリケーションのさまざまなコンポーネントの依存関係をすべて理解し、適切にデプロイされていることを確認することが容易になります。 Kubernetes クラスターを詳しく見る EKS コンソールは AWS でホストされるため、追加のセットアップや設定は不要です。コンソールを開き、クラスターを選択するだけです。 Overview タブで、クラスターのワーカーノード一覧が表示されていることにまず気づくでしょう。Kubernetes コントロールプレーンから見て、これらのノードは Kubernetes アプリケーションが実行されるコンピューティングリソースです。ノードをクリックすると、Kubernetes API サーバーがこのノードについて知っているすべての情報が、もう少し詳しく表示されます。さまざまなノードをすばやく探索し、関連するEKS のマネージド型ノードグループと、そのノードが表す […]

Read More

IoT@Loft #16 ロボティクスにおけるIoTの活用

こんにちは。AWSソリューションアーキテクトの原田です。 11月18日に開催された IoT@Loft 第16回目のテーマは、「ロボティクスにおけるIoTの活用」でした。 この記事では、各LTの内容を登壇資料とダイジェストでご紹介します。また参加者から頂いた質問、登壇者からの回答も掲載します。

Read More

[AWS Black Belt Online Seminar] AWS IoT Greengrass 資料及び QA 公開

先日 (2020/12/15) 開催しました AWS Black Belt Online Seminar「AWS IoT Greengrass」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20201215 AWS Black Belt Online Seminar AWS IoT Greengrass AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. IoTでデバイスが多量にある時にLambdaがコールドスタートになる可能性があると認識してますが、それは仕方がないのでしょうか。IoTの多量のデバイスが一気にLambdaに処理を投げるようになった瞬間にLambdaが動いてなければコールドスタートするまでキューがたまり続けてしまうのでしょうか。デバイスや取得しているデータによってはそれらの時間のロスは致命的になるかもしれないという危惧があるのですが。 A. クラウドで実行するLambdaでは、実際に実行する環境にパッケージを持ってきて、展開し、初期化処理を行うためその時間を気にされているかと思いますが、Greengrass上で実行するオンデマンドLambdaの場合は実行に必要なものはすべてデバイス上に展開されているため、起動は素早く行われます。しかし、初期化処理等で重い処理がある場合は起動が遅くなるケースは考えられますので、そのような場合は実行方法をLong Lived Lambdaとして設定することで、Greengrass Coreが起動すると同時にLambdaが読み込まれ初期化処理を済ませておくことが出来、メッセージが届いてからハンドラで実行するまでの時間を早めることも可能です。ただし、どちらの場合でも処理できる以上のメッセージが届くとキューが溢れてしまいますので、メッセージを送る頻度や処理時間を改善する必要はあります。 —– 今後の AWS Webinar | イベントスケジュール 直近で以下を予定しています。各詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております。 —— AWSome Day Online Conference 「AWSome Day Online」は、AWSの主要サービスや基礎知識を約 3 時間という短い時間で、ポイントを押さえて紹介いたします。技術的な面だけではなく、AWS クラウドを学ぶために必要となる知識を身に付けたい方、エンジニアのみならず、営業職、プリセールス職、学生まで幅広い方々におすすめします。 ※この回ではAWSエキスパートによる技術的な内容についてチャット形式でのQ&Aを実施します。 ※AWS サービスの導入に関するご相談も同時にチャット形式にて対応します。 ※2020年は毎月第一水曜日に開催します。 日時:2021 年 2 […]

Read More

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

先日 (2020/11/25) 開催しました AWS Black Belt Online Seminar「AWS CodeBuild」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20201125 AWS Black Belt Online Seminar AWS CodeBuild AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. プロキシサーバが必要なのはどんなケースでしょうか? A. システム要件によりプロキシサーバを経由する必要がある場合にご利用ください。 例:オンプレミス上のプロキシサーバを経由する必要がある、アクセスログを残す必要があるなど。 Q. テストレポートは、CodeBuildの実行履歴からたどれるのでしょうか A. テストレポートは以下よりご確認いただけます。 ビルド履歴のレポートタブ レポートグループおよびレポート履歴 Q. phasesでプロセスを分けるメリットは何でしょうか? A. 任意のフェーズに全ての処理を記述することも可能ですが、フェーズを分けることでビルド仕様の可読性が上がる、フェーズ毎に run-as で実行ユーザを変更できる、フェーズ毎に通知を受け取れるなどがあるかと思います。 Q. CodeBuildを使ったテスト方法を知りたいです。 A. AWS CodeBuild のドキュメントにいくつか例がございます。こちらをご参照ください。 Q. AWS CodeBuild に Heroku/GitLab「アプリの確認」に似た機能はありますか?そうでない場合、AWS サービスの組み合わせによる同様の機能はありますか? A. 同様の機能はございませんが、ソースリポジトリへのプルリクエストをトリガーに、確認用環境構築を自動化する仕組みを作成することで同様のことは可能かと思います。確認用環境のリソース作成には AWS CloudFormation 、デプロイには […]

Read More

Amplify CLIを使い、労力ゼロでGraphQL/REST APIやウェブホスティング用にコンテナをデプロイする

この記事は、Zero-effort Container deployment for GraphQL and REST APIs and Web Hosting with Amplify CLIを翻訳したものです。 AWS Amplifyを使うことで、最速かつ簡単に、AWSでクラウド対応のモバイルアプリケーションやウェブアプリケーションを構築することができます。Amplifyは、フロントエンドのウェブ開発者やモバイル開発者が AWSの豊富なサービス群を活用して、革新的で多機能なアプリケーションを構築できるよう、ツール類や各種サービスを一通り備えています。 本日リリースしたAmplify CLIをお使いになることで、フロントエンドのウェブ開発やモバイル開発に携わるお客様は、コンテナを使ってAPI(GraphQL/REST)をデプロイしたり、ウェブアプリケーションをホスティングできるようになります。お客様ご自身のDockerfileまたは Docker Composeを持ち込むことで、Amplify CLIは、AWS Fargateを使用してコンテナを自動的にビルド、パッケージ、デプロイします。 メリット: 移植性の高いバックエンドの構築 – Amplify CLIは、シンプルなコンテナテンプレートを用意しているためすぐに始められます。または、お客様のチームがAPIやホスティング用のコンテナを既に使用している場合は、そのコンテナを利用することができます。 コンテナのデプロイパイプラインがすぐに使えるインフラ構成 – Amplify CLIは、VPC、サブネット、NACL、IAMポリシー、およびその他のセキュリティなどのインフラを管理するため、AWSに関する事前知識やインフラの実務経験は全く必要ありません。コンテナ間のネットワーキングは自動的に処理され、ホスティングされたサイトのSSL生成も自動的に処理されます。 ビルド&デプロイパイプラインを労力をかけることなく作成 – Amplify CLIはCodePipelineを作成し、イメージをビルド、デプロイします。パイプラインには、ビルドアーティファクトやイメージに対するライフサイクルポリシーなど、コスト最適化のベストプラクティスが備わっています。ビルドしてAWSにデプロイするためにDockerをお使いのシステムにインストールする必要すらありません。 構築するもの : 初めに、乱数を返すExpressJSサーバーを構築 次に、Python/Flask乱数生成サーバーでFizzBuzzアルゴリズムを実行する、ExpressJSを構築。 前提条件: 最新のAmplify CLIをインストール ターミナルを開き、 npm install -g @aws-amplify/cli を実行し、最新のAmplify CLIに更新。 Amplify CLIの設定 Amplify CLIをまだ設定していない場合は、ドキュメントページのこちらのガイド に従ってください。 […]

Read More

新機能 – AWS Systems Manager Fleet Manager

クラウド環境とオンプレミス環境全体で、ますます多様化する IT インフラストラクチャのポートフォリオ管理に関する課題に、組織とそのシステム管理者は日常的に直面しています。さまざまなツール、コンソール、サービス、オペレーティングシステム、手順、ベンダーはどれも、比較的よく見られまた関連性のある管理タスクを複雑にしています。ワークロードが最新化して Linux やオープンソースのソフトウェアが採用されるようになると、上記のシステム管理者は、Windows バックグラウンドからの GUI ベースの管理ツールに精通していても、新しいツール、アプローチ、スキルセットに継続的に適応し、迅速に学習する必要があります。 AWS Systems Manager は、AWS およびオンプレミスのリソースを管理できるオペレーションハブです。本日よりご利用いただけるようになった Fleet Manager は、Systems Manager の新しいコンソールベースの機能です。これにより、システム管理者は、SSH または RDP を使用したリモート接続に頼ることなく、オペレーティングシステムに依存しない方法で、マネージドインスタンスのフリートを単一の場所から表示および管理できるようになります。ドキュメントで説明されているように、マネージドインスタンスには、AWS クラウドとオンプレミスの両方で Windows、Linux、macOS オペレーティングシステムを実行しているインスタンスが含まれます。Fleet Manager では、コンピューティングインスタンスが存在している場所に関係なく、それらを集約して表示します。 クラウドサーバーかオンプレミスサーバーかに関わらず、必要なものは、各マネージドサーバーに Systems Manager エージェントがインストールされており、AWS Identity and Access Management (IAM) のアクセス許可および、Systems Manager の Session Manager で有効になっている AWS Key Management Service (KMS) だけです。これにより、現在使用している高価な管理ツールのライセンス料金を支払う必要がなくなり、複数の環境で実行しているサーバーのリモート管理を、容易かつコスト効率に優れたアプローチで実現できます。先に述べたように、macOS 上で実行中のインスタンスでも動作します。エージェントソフトウェアとアクセス許可を設定すれば、Fleet Manager を使って単一のコンソール環境からサーバーを検索および管理できます。例えば、Amazon CloudWatch エージェントをインストールすることなく、ファイルシステムの移動、Windows サーバー上のレジストリの操作、ユーザーの管理、ログのトラブルシューティング (Windows イベントログの表示を含む)、一般的なパフォーマンスカウンターのモニタリングを行うことができます。 […]

Read More

新機能 – AWS Systems Manager がアプリケーション管理を統合

統合された、シンプルな運用管理を求めるのは、クラウドインフラストラクチャだけに限られるものではありません。当社のお客様では、アプリケーションのポートフォリオを監視および管理するための、“1 つの枠組みによる” アプローチを、お求めになることが増えています。 これらのお客様がおっしゃるのは、アプリケーションの検出と調査に、余分な時間と労力がかかっているということです。DevOps エンジニア達は、調査対象であるアプリケーションの問題に関するコンテキストを取得するために、一般的に複数のコンソールやツールを使用しているというのがその理由です。さらに、リソースの使用量に関するメトリクスや、ログなどの情報ソースを参照することも必要になります。ここで言う “アプリケーション” とは、アプリケーションコードのみを指すのではありません。アプリケーションをホストするためのユニットとして機能するリソースの論理グループや、オペレータのための所有権の境界、さらに開発、ステージング、および実稼働などの各環境なども含まれています。 今回、AWS Systems Manager の新機能として、この Application Manager をご紹介できる運びとなりました。Application Manager を使用すると、複数の AWS のサービスや、Systems Manager の機能に関する運用情報を1 つのコンソールに集約することで、アプリケーションの運用データを簡単に表示できるようになります。 さらに便利な機能として、このサービスでは、アプリケーションの自動検出も行えます。現在、この自動検出機能は、AWS CloudFormation スタックおよび Amazon Elastic Kubernetes Service (EKS) クラスターで実行されているアプリケーション、または AWS Launch Wizard から起動されたアプリケーションに対しご利用いただけます。また、アプリケーションは、リソースグループからも検出できます。 自動検出機能の大きなメリットは、アプリケーションのコンポーネントやリソースが、継続的かつ自動的に最新の状態に維持されることです。加えて、必要に応じてコンポーネントを手動で追加または削除すれば、アプリケーションをいつでも改訂することも可能です。 検出されたアプリケーションを単一のコンソールに統合することで、運用上の問題をより簡単に診断し、最小限の時間と労力で解決できるようになります。アプリケーションのコンポーネントまたはリソースをターゲットとする自動 Runbook を実行することで、運用上の問題の修復に役立てることができます。1 つのコンソールを離れることなく、任意のアプリケーションについてリソースを選択し、関連する詳細内容を調べられます。 たとえば、アプリケーションにより Amazon CloudWatch ログ、運用メトリックス、AWS CloudTrail ログ、および設定変更を表示できるので、複数のツールやコンソールを使用する必要がなくなります。担当のエンジニアは、問題をより迅速に把握できるので、その解決にかかる時間を短縮できます。 Application Manager を使用したアプリケーションの調査 Application Manager には、Systems Manager のホームページからアクセスできます。ページが開いたら、検出されたアプリケーションの概要が表示され、アラームが存在するかをすぐに確認できます。コンテキストを Amazon CloudWatch […]

Read More

AWS CloudShell – AWS リソースへのコマンドラインアクセス

多くの自動化を構築していても、Infrastructure as Code (IAC) の実践に優れていても、ペットから家畜への移行が成功したとしても、コマンドラインで AWS リソースとやり取りする必要が時折出てきます。設定ファイルの確認や調整、本番環境での迅速な修正、または AWS の新しいサービスや機能を試す必要があります。 ウェブブラウザでの作業が最もストレスがないと感じているお客様もいますが、独自のコマンドラインインターフェイス (CLI) を設定またはカスタマイズしていることはありません。こうしたお客様は、クライアントアプリケーション、パブリックキー、AWS 認証情報、ツールなどを使いたくないと言います。これらの手順はどれも難しいことではないし、時間がかかることもありません。私たちはいつでも複雑さや手間の多い作業が増えているお客様のお手伝いをする準備ができています。 AWS CloudShell の導入 本日、AWS は AWS CloudShell をローンチしました。これは、AWS 対応のシェルプロンプトの作業を簡単かつセキュアにし、できるだけ手間を少なくすることを目的としたものです。CloudShell で実行するすべてのシェル環境には、AWS コマンドラインインターフェイス (CLI) (v2) がインストールおよび設定されており、AWS のコマンドを即座に実行できます。環境には Python と Node のランタイムも含まれ、今後さらに多くのランタイムを追加する予定です。 開始するには、AWS マネジメントコンソールで CloudShell アイコンをクリックします。 ほんの数秒でシェルが自動的に設定され、すぐに最初の AWS のコマンドを発行することができます。 シェル環境は Amazon Linux 2 に基づいています。ホームディレクトリにはリージョンごとに最大 1 GB のファイルを保存でき、そのリージョンでシェルを開くたびに利用可能になります。これには、.bashrc ファイルやシェル履歴ファイルなどのシェル設定ファイルが含まれます。 SSO または AWS マネジメントコンソール (フェデレーションロールを含みます) にログインできる任意の IAM […]

Read More

AWSが支えるCOVID-19との闘い④──宮田裕章教授が語る「データ駆動型社会」という未来 ―「誰一人取りこぼさない」を実現するためのAWSの役割とは?

これまで本連載では、ビッグデータを活用した感染防止プロジェクトの目的や、主に慶應義塾大学の研究室において、どのような課題を解決しながらデータ分析をしてきたかなど、実際の担当者の方々にお聞かせいただきました。シリーズ最後の第4回では、今一度プロジェクトを発案された宮田裕章教授にご登場いただき、プロジェクト全体の成果、そして教授が描く今後のデータ駆動型社会のビジョンについてお話いただきます。今回も前回に引き続き、当社執行役員の宇佐見 潮がお話を伺いました。 ビッグデータ活用が新型コロナ第二波の抑制に貢献 神奈川県が開設する「新型コロナ対策パーソナルサポート(行政)」は、県民が自らの体調や症状に応じ感染症に関わる情報を入手するサービスとして、現在も広く活用されています。その上で、同県では得られた情報分析の結果を、県内の感染状況の把握や対策の立案に活かしました。そもそも「EBPM(証拠に基づく政策立案)」を目指してスタートしたプロジェクトです。当然、宮田教授は集めたデータがどれだけ判断の基となることができたかにこだわりました。 「実際、PCR検査で陽性判定を受けた人の情報と、パーソナルサポートにより得られた情報の分析結果を突き合わせてみると、データの精度は一定のレベルに達しており、感染者の現状を推計できることが確認できました」と宮田教授は一定の評価を下しています。

Read More