Amazon Web Services ブログ

Category: Events

Amazon ECRのクロスリージョンレプリケーションが公開されました

この記事は Cross region replication in Amazon ECR has landed を翻訳したものです。 本投稿は Michael Brown と Michael Hausenblas が共同で作成しました。 Amazon Elastic Container Registry (ECR) のリージョン間でコンテナイメージを自動的にレプリケーションする機能は、最も要望の多かった機能の一つでした。これまでは自分でレプリケーションを実装しなければならなかったのですが、今では AWS に作業を任せて、お客様はアプリケーションの構築と実行に集中できるようになりました。この記事では、ECR のクロスリージョンレプリケーション (CRR) がどのように機能するのか、そしてどのようにしてその恩恵を受けることができるのかを説明します。

Read More

SAP on AWS: 2020年振返り

はじめに 2020年を振り返ると、どれだけ信じがたい出来事が起きたかということを認めなくてはなりません。全世界的にCOVID-19やその他の世界の出来事によって私たちの生活様式が変化し、多くの人々にとって困難なものとなりました。このパンデミックにより、企業は顧客や従業員のニーズを満たすために、ほぼ即座に運用上の変更を余儀なくされました。また、多くの企業がクラウドサービスの利用を始めました。 この数週間にわたり、毎年恒例のre:Inventカンファレンスの一環として、私たちは多くのお客様からの声を聞く機会がありました。その数社はSAPトランスフォーメーションのストーリーを世界へ共有するためのバーチャルステージを行いました。:

Read More
週刊AWS

週刊AWS – 2020/12/14週 (re:Invent 特別編集号)

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も週刊AWSをお届けします。 3週間に渡って開催した AWS re:Invent 2020 のWave 1が終了しました。今回は初のオンライン開催でしたが、みなさま楽しんでいただけましたでしょうか?第1週と第2週のセッションの多くはオンデマンド配信が開始になっています。こちらにカテゴリ別に整理されていますので、見逃した内容がある方はぜひチェックしてみてください。 今号は引き続きre:Invent特別編集号として、筆者らが独断でピックアップした重要アイテムを紹介する形でお送りします。今号はKeynote (Werner Vogels)とLeadership Session (IoT)で発表されたものを中心にご紹介します。 それでは、先週の主なアップデートについて振り返っていきましょう。

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

[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 from Amazon Web Services Japan 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 […]

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 from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. プロキシサーバが必要なのはどんなケースでしょうか? A. システム要件によりプロキシサーバを経由する必要がある場合にご利用ください。 例:オンプレミス上のプロキシサーバを経由する必要がある、アクセスログを残す必要があるなど。 Q. テストレポートは、CodeBuildの実行履歴からたどれるのでしょうか A. テストレポートは以下よりご確認いただけます。 ビルド履歴のレポートタブ レポートグループおよびレポート履歴 Q. phasesでプロセスを分けるメリットは何でしょうか? A. 任意のフェーズに全ての処理を記述することも可能ですが、フェーズを分けることでビルド仕様の可読性が上がる、フェーズ毎に run-as で実行ユーザを変更できる、フェーズ毎に通知を受け取れるなどがあるかと思います。 Q. CodeBuildを使ったテスト方法を知りたいです。 A. AWS CodeBuild のドキュメントにいくつか例がございます。こちらをご参照ください。 Q. AWS CodeBuild に Heroku/GitLab「アプリの確認」に似た機能はありますか?そうでない場合、AWS サービスの組み合わせによる同様の機能はありますか? […]

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 Systems Manager Change Manager のご紹介

皆様の元には、お客様からのフィードバックが日常的に届いていることでしょう。それを基に、アプリケーションやインフラストラクチャをくり返し修正し、イノベーションのための改善をされていると思います。クラウドに置いた IT システムの変更は継続的なものです。ただ、現実を見てみると、稼働中のシステムで何かを変えることは、何かを壊すことでもあります。この結果、時には予測できない副作用を引き起こす危険があるのです。テストを何回行ったのかは重要ではありません。一方、変化を加えないということは停滞を意味します。その後に続くのは的外れのサービス提供、そして、その終了という結末です。 そのため、あらゆる規模とタイプの組織が、変更を上手に継続するための文化を、内部に醸成しています。一部の組織では、ITIL v4 で定義されている変更管理プロセスなどのシステムを採用しています。DevOps や、継続的デプロイを導入していたり、他の方法を採用している組織も存在します。いずれの場合にしても、変更管理プロセスを上手く運用するのに大切なのは、ツールを用意することです。 今回、AWS Systems Managerの新しい変更管理機能である、AWS Systems Manager Change Manager がリリースされました。このサービスにより、アプリケーションの構成やインフラストラクチャに対し運用エンジニアが行う、運用的な変更の追跡、承認、実装が簡素化されます。 Change Manager の使用には、主に 2 つの利点があります。第 1 の利点は、アプリケーションの構成やインフラストラクチャに加えられた変更の安全性を向上させ、サービスの中断のリスクを軽減することです。変更内容を追跡し、承認されたもののみが実装されるようにすることで、運用的な変更をより安全に実施できます。第 2 の利点は、AWS Organizations や AWS Single Sign-On などの他の AWS のサービスと緊密に統合されていることです。さらに、Systems Manager の変更カレンダーや Amazon CloudWatch アラームとも連携しています。 Change Manager では、組織全体で行われた変更、その目的、それらを承認および実施した人物などについて一貫性のある監査を行いレポートを作成することで、変更に対する責任を担保できます。 Change Manage は、AWS リージョン間、あるいは、複数の AWS アカウント間で機能します。Organizations、あるいは、AWS SSO と緊密に連携しているので、一元的なポイントからの変更の管理や、グローバルインフラストラクチャ全体に対する制御された方法でのデプロイが可能になります。 関連用語 AWS Systems Manager Change Manager は、単一の […]

Read More