This article was contributed by Mr. Yasuo Matsuura, an executive officer, efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. The introduction will be divided into 2 parts: the first half and the second half. This article is the second half of that. The serial articles have also been published as serialized articles, so please be sure to check them out. Article #2 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. (Part 2) — First half ” Article #3 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. (Part 3) — First half ” Examination of directions in the current smart meter systems As a response to current smart meter system issues described in “Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc.” , clouds utilization, mainly AWS, which have advanced widely as a technological trend in the IT field would be an option. By utilizing the cloud, almost all “hardware replacements” associated with running out of maintenance of server hardware, which are unavoidable in on-premise equipment, are unnecessary, and related operations are expected to be drastically reduced. Also, even in response to server enhancements associated with an increase in system load, in the case of cloud utilization, server resources can be changed simply by setting resources on the GUI, and depending on the design, there is no need to consider even scaling out the server due to the autoscaling function. Furthermore, by placing data on the cloud, various data analytics services can also be used with agility, so flexible and advanced expansion of data utilization can also be realized. Additionally, as a basis for the study, Kansai Electric Power, Inc., which is our parent company, completed research aimed at utilization and technical verification related to applicability based on trends in cloud market expansion, and as a result, decisions were made regarding the introduction and use of the cloud, such as having already decided to adopt AWS standards (*1). (*1) AWS Summit 2022 “Cloud Standardization and Guideline Formulation Initiatives Supporting Kansai Electric Power Inc’s Digital Transformation and AWS Use Cases” Partly against this background, it was a natural progression to begin investigating and examining cloud utilization in order to solve various issues in the on-premise environment in smart meter systems. Internal discussion related to cloud conversion From the background described above, it was decided to proceed with technical research and studies on the conversion of smart meter systems to the cloud, but at first, there were strong opinions within the company that felt a vague sense of anxiety about the cloud. In a situation where stable operation has been achieved over 10 years by constructing equipment on-premise and establishing business schemes, it is natural to feel uneasy about daring to choose the cloud, so we decided to proceed with a careful exchange of opinions, including pros and cons. As for a vague sense of anxiety, for example, “Is the security aspect of the cloud OK?” , “Can it also be used in core business systems?” , “Are there any concerns about business withdrawal, etc.?” , “Are there any concerns about aggressive price increases peculiar to foreign capital?” , “Is quality guaranteed?” , “Are maintenance and technical support reliable?” There were things like that. In response to vague anxiety and questions, we collected knowledge about cloud services, information related to industry trends, and examples of AWS and various companies, etc., proceeded with fact-checking, deepened the understanding of stakeholders through information sharing, and dispelled the sense of anxiety at the initial stage of the study. Also, with regard to the security aspect and the basic appropriateness of cloud utilization, a situation was fostered where awareness can be shared within the company and can be thoroughly examined and exchanged, such as “ensuring security in system construction depends on the design of cloud users and is definitely feasible,” and “even in core business systems in financial institutions and companies related to social infrastructure, there are no barriers to introduction in terms of technology,” etc. In-depth discussions on going to the cloud have progressed. For example, “How does the cloud specifically deal with the risk of intrusion from the internet?” , “Won’t disaster recovery take longer in the cloud? Isn’t disaster recovery faster with our dedicated hardware?” , “By moving the system to the cloud, network costs will remain high, and overall costs will not be high?” We discussed various questions such as these and exchanged opinions. After collecting information on each point of discussion by referring to AWS cloud implementation cases, opinions from both sides were carefully sorted out, and discussions continued in a frantic manner. As a result, there was a shared perception that in addition to security aspects, cloud can ensure quality equal to or higher than that of on-premise in terms of availability. In the study on network cost aspects, it is clear that a network linked line with the cloud would increase costs by itself, and it was clarified that there is a need for a comprehensive evaluation from the viewpoint of TCO of the entire system rather than an individual evaluation. Next, discussions moved on to choosing a cloud service, but as described above, Kansai Electric Power Inc. had already adopted AWS as a standard cloud, and as a result of a comprehensive examination of its performance evaluation, market share, cost, customer-oriented way of thinking in service development and provision, support aspects, and ease of obtaining technical information etc., we also shared our understanding in the direction of adopting AWS. Based on the discussion within the company relating to a wide range of cloud conversion as described above, internal understanding, including technical aspects, was fostered about the transition to the AWS cloud, and the direction was solidified. Regarding cost estimation and economic evaluation What I focused on and was aware of during approximate cost calculation and economic evaluation related to the migration of smart meter systems to AWS was to identify the types of “costs that increase” and “costs that decrease” with the transition to the cloud. At this time, we are referring to prior cases and achievements within the Group. In particular, as our prior example, we placed importance on the fact that by utilizing not only IaaS (Infrastructure as a Service) but also PaaS (Platform as a Service), we were able to achieve cost reduction while realizing improvements in flexibility and availability, which are advantages of the cloud. AWS managed services are a mechanism that supports this. Another aspect of the benefits of utilizing managed services is that you can enjoy a pay-as-you-go (pay only for what you use) way of thinking when using the cloud. It helped reduce costs by eliminating the need for procurement that anticipates the moment when resource consumption is maximum, such as conventional hardware batch procurement. On the other hand, there were also items that could not be fully evaluated by our desk study. Specifically, although it is possible to implement functions in the current environment directly into the cloud, there is a possibility that greater effects can be obtained in terms of cost by reviewing the implementation method itself in line with the AWS migration. Although we have organized and recognized these items, since it takes time to determine technical feasibility, including security aspects, we have decided to temporarily remove them from cost evaluation targets at the initial stage of the study. As a result of cost estimation in line with this fixed way of thinking, we were able to establish the outlook that cost advantages can always be secured. Determination of a major direction based on the initial review results Based on such a wide range of research studies on cloud conversion and internal discussion based on it, we came to a management decision on the direction of “promoting AWS migration on the premise of cost reduction” for the current smart meter system in April 2022. Establishing a Project Management formation and Accelerating Examination to the cloud 　 When promoting this project in line with the precondition of “promoting AWS migration on the premise of cost reduction,” the point of “reliably achieving economic rationality” became a very important theme in deepening AWS migration studies. In order to realize a cloud migration that can reliably ensure economic rationality, we invited AWS Professional Services from this phase to the position of proactively promoting project management in both technology and business, and we decided to accelerate project promotion by carrying out overall control over each system vendor that has jurisdiction over the subsystem from the same standpoint as our company. Since then, in promoting the project, we have clarified the basic stance and implementation policy related to the AWS migration effort, clearly message it to each system vendor, and consider and promote it based on that, so we went in and discussed with AWS Professional Services on everything from organizing the basic stance to the content of the message. In particular, we have vigorously examined policies to migrate to the cloud. For example, at the beginning of the study on migrating the current system to AWS, I thought that the idea of simply migrating servers to the cloud without putting as much effort as possible on applications and middleware would be optimal in terms of cost and lead time. However, we have come to the conclusion that it is not simply a “cloud lift” that migrates servers to the cloud, but rather the idea of a “cloud shift,” which actively utilizes managed services and optimizes the structure on AWS, can enjoy advantages unique to the cloud and secure high economic rationality, including investments related to improving maintenance and operability and ensuring availability. (Figure 1) Figure 1 Reducing the load on construction and operation by utilizing managed services In other words, we have decided to stop implementing applications that have developed their own server environments on-premise on AWS in the same way as before, and those that can be replaced with cloud services will actively switch to service use. In order to implement this implementation policy, modifications to the current system will occur. In this process, in parallel with accelerating technical studies for active adoption of managed services, we identified functional requirements that were no longer needed, sorted out and reviewed system requirements based on that, and sorted out the direction of system improvement that was conscious of the transition to next-generation systems. After clearly establishing such an implementation response policy and unifying decisions with each vendor, it was decided to step into the design phase for the cloud shift. Our examination direction on next-generation systems In parallel with the consideration of adopting AWS for the current smart meter system, the study of a next-generation smart meter system also progressed. From a system development perspective, as AWS adoption studies are progressing with the current system, the next generation did not deny this, but rather proceeded with the study in the direction of enjoying even more cloud benefits. In particular, in next-generation smart meter systems, in order to respond to environmental changes toward carbon neutrality, strengthen power resilience by flexibly utilizing data obtained from smart meters, realize further advancement of distribution grids that contribute to mass introduction of renewable energy, and further improvements in customer service are inevitable, so we believe it is essential to develop flexible systems that can steadily respond to these requirements. (Figure 2) Figure 2 Promoting Electric Power DX Using Next-Generation Smart Meters Direction of next-generation system development In order to realize the development stance for next-generation smart meter systems, internal discussions were conducted in the direction of adopting a more modern approach in system development. While steadily realizing the robust security measures required for smart meter systems and the high resilience that supports transmission and distribution business continuity, it is necessary to create a system that can respond to additional tasks and requirements anticipated in the future. In order to realize this idea, in our next-generation smart meter system, we aim to expand functions and minimize the area of influence when a failure occurs while introducing the idea of microservices and loosely connecting each component. Additionally, in order to steadily realize microservices, we have introduced a serverless architecture, utilized managed services more actively than current systems, and set out a direction aimed at reducing operational load. (Figure 3) While steadily implementing these policies, we aim to realize an even more robust and flexible smart meter system by fully utilizing cutting-edge technology in cloud services. Based on these ideas and policies, our next generation smart meter system development project is still underway. Figure 3. The direction of our smart meter system development Migrations of our current systems and next-generation systems Finally, I will mention future prospects for current systems and next-generation systems. As of 2025, our smart meter system is scheduled to run in parallel with the current system and the next-generation system. This direction was based on the fact that the characteristics required for each are different, and that they aim to improve customer service by quickly utilizing next-generation smart meters. Meanwhile, we will consider reducing TCO, including operating load etc., and aim to migrate current systems to next-generation systems at an early stage. Even in examining the direction of migration, we have examined the current system by incorporating the idea of “cloud shift” which optimizes the system on AWS by actively utilizing managed services, rather than a “cloud lift,” so we have come to see the feasibility of a system that takes into consideration the smooth degeneration of the current system with an eye on the transition to a next-generation system. Conclusion In this article, I have introduced the overall picture of discussions on cloud utilization in our smart meter systems. Article #2 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. (Part 2) — First half ” is also published, so please be sure to check it out as well. Author Yasuo Matsuura Executive Officer (Power Distribution Department, Information Technology Department), Kansai Transmission and Distribution Inc. Since the early 2000’s, he has been involved in technology development for communication media applied to next-generation distribution networks, and has been in charge of smart meter system development and implementation projects since 2010. Based on this experience, they investigated and presented issues related to data utilization from the overall picture of smart meter systems at domestic and international venues, such as setting up a working group on smart meter data utilization at CIGRE (International Council on Large Electric Systems), and contributed to raising awareness of smart meters in Japan as an important key device essential for realizing a decarbonized society, improving resilience and improving efficiency. In 2020, I participated as a committee member in the next-generation smart meter system review meeting that was resumed under the call of the Agency for Natural Resources and Energy, and led discussions on the structure, function, performance, etc. required for next-generation smart meters by utilizing the experience of introducing current smart meters and knowledge from foreign surveys. In fiscal 2022, in addition to completing the introduction of all of the company’s current smart meters, a next-generation smart meter system concept that could be a data platform was drawn up, and the company promoted studies. This article was translated by AWS Blake Horike, Riho Matsui, and Satoshi Aoyama.

This article was contributed by Mr. Yasuo Matsuura, an executive officer, efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. The introduction will be divided into 2 parts: The first half and the second half. This article is the first half of that. The serial articles have also been published as serialized articles, so please be sure to check them out. Article #2 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. (Part 2) — First half ” Article #3 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. (Part 3) — First half ” Introduction Kansai Transmission and Distribution Inc. (hereafter, our company) inherited the general transmission and distribution business from The Kansai Electric Power Co, Inc. in April 2020 in line with the revision of the Electric Power Business Law to ensure even greater neutrality in the transmission and distribution business, and commenced operations. In the process of depicting what our company aims for in the future and working company-wide on digital transformation (DX) where we transform ourselves toward that form, we have now decided to develop a smart meter system centered on the cloud, which is the first in Japan (*1). We plan to blog about this initiative in a trilogy series as a whole. This time, as the first part, I will tell you about the progress of internal discussions leading up to decisions related to cloud and AWS adoption in smart meter systems. From the next session onwards, I will introduce specific directions and initiatives for next-generation smart meter systems that assume the use of AWS, and the situation of solving issues related to the cloud shift of current smart meter systems (*2). (*1) “ We have decided to develop a cloud-centered system for the first smart meter system in Japan (Japanese) ” (our website,2023/3/31) (*2) The installation of our current smart meter was completed in March 2023. After that, as the validity period (10 years) of current smart meters gradually expires, replacement with next-generation smart meters is scheduled to begin in 2025. Figure 1 Excerpt from our company’s press release What is a smart meter system A smart meter system is a system that collects and stores customer electricity usage remotely, automatically, and regularly via a communication network, and consists of a smart meter, a communication network, a system that manages the collected data (meter data collection/management system), and a system (business system) that is responsible for operations related to electricity usage. A smart meter consists of a metering unit that measures and records the customer’s electricity usage and a communication unit that transmits the measured electricity usage data to a higher-level server. (Figure 2) Figure 2 What is the smart meter system Not only has significant progress been made from the previous generation meter once a month to remote/automatic meter reading every 30 minutes, but by transmitting electricity usage data from smart meters to terminal devices (home energy management systems, building energy management systems, etc.) in the customer’s home, it is possible to grasp the time periods when electricity usage is high, etc., and achieve more effective energy saving It became. The introduction of next-generation smart meter systems with revised specifications and improved functionality is scheduled to begin in 2025 compared to the current smart meter system, which was introduced in the first half of the 2010’s and is expected to be completed in all households throughout Japan in early 2020’s. Moreover, that smart meters are the accuracy and the appropriateness as metering devices are guaranteed by the certification, and since the validity period of this certification is 10 years, it will basically take 10 years to replace all meters with smart meters. Implementation history and actual situation We have been proceeding with research and development of communication systems since the late 1990’s, with the aim of improving the efficiency of operations around measuring instruments. This development concept later became a general-purpose concept called a smart meter. At that time, running costs for communication networks such as mobile phone systems were high, so the major issue was how to build a communication network with connectivity and high reliability, using self-operated communication networks as the main focus. Also, at that time, analog measuring instruments called mechanical ones were the mainstream. In 2005-2006, when a certain level of research and development aimed at making measuring instruments smart was established, discussions were held within the company, and full-scale studies aimed at making smart meters began. At that time, the term “smart meter” did not exist, and within our company, smart metering systems were called “new metering systems” and development was promoted. At that time, it was natural to visually check the meter’s display and meters, and to work on the meter side for connection/disconnection associated with moving etc., but since these operations changed drastically due to being replaced by a new metering system, dozens to one hundred dozen internal stakeholders went through one place, accumulated discussions, and repeated discussions decided the desired form of work one by one. Based on these discussions, as for system development, development vendors were decided in 2006, system requirements were also determined, development with each vendor was carried out in 2007, multi-vendor tests from communication networks to systems were carried out at the end of the same year, trial implementation began in April 2008, and full implementation began in 2012. At the beginning of implementation, we faced many new issues, such as communication congestion events in communication networks that could not be anticipated at the time of development, and we faced great hardships, but by resolving them, we steadily improved the reliability of the new metering system. After that, momentum for the introduction of smart meters increased throughout Japan, and full-scale implementation by the 10 electric power companies at the time began in 2014, and was gradually developed, and we completed the introduction of all households in March 2023. Until now, we have been actively working to realize safe and reliable meter reading work, improve convenience for customers, and rationalize the configuration of power distribution equipment based on accumulated electricity usage data by utilizing smart meter systems. Utilization of electricity usage data We began full implementation of smart meters in 2012, and completed the introduction to all households in March 2023. We have been working on utilizing electricity usage data collected every 30 minutes from the beginning of implementation, and we have promoted data utilization in a practical manner, such as the normalization and rationalization of power distribution equipment. On the other hand, as described later, there was not the concept of a cloud system at the time of development, so an on-premise data collection system is being built in the current smart meter systems. For this reason, there were issues with the scalability of server systems to accommodate smart meters that are gradually expanding. Furthermore, detailed specification adjustments between vendors associated with system construction by multiple vendors are necessary, and furthermore, since it is composed of vendor-specific specifications, there are issues with flexible data extraction and processing according to needs, and there were hurdles in realizing thorough data utilization. In this situation, based on recent heightened interest in strengthening resilience and progress in the introduction and expansion of the distributed energy resources, starting with renewable energy etc., the Agency for Natural Resources and Energy established a next-generation smart meter system review meeting in September 2020 as a forum for discussions on advanced use of smart meter systems, and new specifications of smart meter systems suitable for the carbon neutral era and new functions that should be provided It was discussed and examined. Based on current system issues and discussions at the Next Generation Smart Meter System Review Meeting, we have decided to realize both the current system and next-generation system with a full cloud based on AWS, with the aim of improving service levels and social resilience for customers using power networks by flexibly utilizing data obtained from smart meters, and improving social resilience. (Figure 3) Figure 3 Full Cloud Transition of Current and next-generation system The scope of our smart meter systems on this article The overall overview of smart meter systems, as shown in Figure 2, generally consists of smart meters installed in each home, communication networks, data centers that collect and store data, and various business systems that are responsible for related tasks. This article focuses on systems configured on AWS, so in this article, as shown in Figure 4, the head end system (Head End System) is responsible for collecting data from smart meters among smart meter systems.(Hereafter, HES), and meter data management systems (Meter Data Management Systems), which are responsible for utilization of collected data and meter management. (The description is specific to MDMS) below. For this reason, unless otherwise indicated, only HES and MDMS are described as smart metering systems in this article. Figure 4 The smart metering system covered in this article Our challenges of the current smart meter systems Since the term “smart meter” did not exist, we have been promoting development by calling it a new metering system. As there is currently no smart meter package software, etc., we have received cooperation from multiple system vendors and have been searching for system configurations and function arrangements through trial and error. As a result, we have succeeded in implementing the system by configuring a system with vendor-specific technology and specifications in an on-premise environment. Since the start of operation of this system, the server scale has continued to expand gradually along with the increase in the number of smart meters installed, while continuous stable operation has been achieved. Our current smart meter systems are facing issues such as economic efficiency and future sustainability issues associated with adopting proprietary OS, commercial databases, and middleware, system blackboxing, and concealment of business processing logic against the backdrop of centralized outsourcing to system vendors due to systems created through these situations. These issues have become extremely important issues for our company, which aims to make advanced use of the huge amount of electricity usage data collected after 100% implementation of smart meters has been completed. Also, in contrast to smart meters, which are being introduced and expanded over 10 years, it was also a major issue that the number of servers increased as the capacity increased, related OS and middleware were out of maintenance, license updates, and server replacement work occurred every year. Regarding these issues, verification work etc. occurred each time, so there were not only economic issues, but also an issue where the workload of members involved in our server maintenance relationship was increasing. Furthermore, in recent years, various issues, including future uncertainty, have become apparent, such as delays in server hardware procurement delivery due to semiconductor exhaustion. Conclusion This article, we have introduced our efforts aimed at cloud adoption of smart meter systems, “up to issues with current smart meter systems.” For the latter half, please see “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. (Second half). ” Author Yasuo Matsuura Executive Officer (Power Distribution Department, Information Technology Department), Kansai Transmission and Distribution Inc. Since the early 2000s, he has been involved in technology development for communication media applied to next-generation distribution networks, and has been in charge of smart meter system development and implementation projects since 2010. Based on this experience, they investigated and presented issues related to data utilization from the overall picture of smart meter systems at domestic and international venues, such as setting up a working group on smart meter data utilization at CIGRE (International Council on Large Electric Systems), and contributed to raising awareness of smart meters in Japan as an important key device essential for realizing a decarbonized society, improving resilience and improving efficiency. In 2020, I participated as a committee member in the next-generation smart meter system review meeting that was resumed under the call of the Agency for Natural Resources and Energy, and led discussions on the structure, function, performance, etc. required for next-generation smart meters by utilizing the experience of introducing current smart meters and knowledge from foreign surveys. In fiscal 2022, in addition to completing the introduction of all of the company’s current smart meters, a next-generation smart meter system concept that could be a data platform was drawn up, and the company promoted studies. This article was translated by AWS Blake Horike, Riho Matsui, and Satoshi Aoyama.

本ブログは 2025 年 11 月 25 日に公開された「 AWS achieves ISO/IEC 42001:2023 Artificial Intelligence Management System accredited certification 」を翻訳したものになります。 アマゾン ウェブ サービス（AWS）は、主要なクラウドサービスプロバイダーとして初めて、AI サービスに対する ISO/IEC 42001 認証を取得したことをお知らせします。対象となるサービスは、 Amazon Bedrock 、 Amazon Q Business 、 Amazon Textract 、および Amazon Transcribe です。 ISO/IEC 42001 は、組織が AI システムの責任ある開発と使用を促進するための要件とコントロールを概説した国際的なマネジメントシステム規格です。 責任ある AI は、AWS の長期にわたるコミットメントです。当初から、AWS は責任ある AI イノベーションを優先し、公平さ、説明可能性、プライバシーとセキュリティ、安全性、制御性、正確性と堅牢性、ガバナンス、透明性を考慮して AI サービスを構築・運用するための厳格な方法論を開発してきました。 AWS はグローバル標準を策定する組織と積極的に協力するステークホルダーです。開発するガイドラインは、明確さ、定義、スコープを改善し、責任ある AI の実践のベンチマークを確立し、リスクに対処するための効果的なオプションに業界の取り組みを集中させることで重要な役割を果たします。私たちのゴールは、リスク管理、データ品質、望ましくないバイアスの緩和、説明可能性など、いくつかの重要な領域で AI 規格の改善に貢献することです。 ISO/IEC 42001 のような技術的な規格は、責任ある AI の開発と展開のための共通的なフレームワークを提供し、ますますグローバル化し AI ドリブンな技術環境における信頼性と相互運用性を育むために重要です。ISO/IEC 42001 認証を取得したということは、AWS が AI の開発、展開、運用に関連するリスクと機会を管理するために積極的な措置を講じていることを、独立した第三者が検証したことを意味します。この独立した検証により、お客様は AWS の責任ある AI へのコミットメントと、AWS サービスを使用して責任を持って AI アプリケーションを構築・運用する能力について、さらに確信を持てるようになります。 Snowflake 社の米国公共部門の VP である Tim Tutt 氏は次のように述べています。「Snowflake では、お客様に AI 機能を提供することが最優先事項です。私たちの製品チームは、責任を持って AI を構築・展開する必要があり、技術的な複雑さがあるにもかかわらずサプライヤーにも同様のことを期待しなければなりません。これが ISO 42001 が私たちにとって重要である理由です。ISO 42001 認証を取得しているということは、その企業が思慮深い AI マネジメントシステムを実装していることを意味します。AWS が ISO 42001 認証を取得したサービスを提供していると知ることで、AWS のサービスの責任ある開発と展開へのコミットメントに自信を持つことができ、私たち自身のお客様への信頼に繋がります」。 ISO/IEC 42001 のような認証は、国内または国際的な認定機関によって認められた認証機関によって発行されます。これは、その認証が信頼でき、独立した検証に基づいていることを示しています。今回の場合、ANSI National Accreditation Board（ANAB）によって認定された ISO 認証機関である Schellman Compliance, LLC が認証を付与しました。 本ブログはプロフェッショナルサービス本部の藤浦 雄大が翻訳しました。

このブログでは、テクノロジーリーダーやフロントエンド、フルスタック、バックエンドの開発者にとって最もエキサイティングなセッションを紹介します。セッションは、中級（200）から上級（400）レベルの内容で、インタラクティブなチョークトーク、ハンズオンワークショップ、コードトーク、講義形式のブレイクアウトセッションを組み合わせたものとなっています。TypeScript、JavaScript、iOS、Android、React Native、Flutter などの開発者がアプリケーションを構築し、テストする際に役立つ最新の AWS ツール、サービス、機能を取り上げます。参加者は、フロントエンド開発者のためにクラウドでの開発者体験がどのように見直されているのかを知り、あらゆる規模のビジネスを強化する方法を発見し、フルスタック AI が Web 開発の未来をどのように形作っているかについての洞察を得ることができます。 AWS re:Invent とは AWS re:Invent はグローバルなクラウドコンピューティングコミュニティのための学習カンファレンスです。このイベントは 2024 年 12 月 2 日 ~ 12 月 6 日まで開催されます。リアルイベントでは、エキサイティングなキーノートアナウンス、ネットワーキング、トレーニング、認定資格の機会、2,000 を超えるテクニカルセッション、 Vendor Expo 、楽しい夜のイベントなどが用意されています。 AWS re:Invent 2024 の開催地 re:Invent がネバダ州ラスベガスに戻ってきました! 会場、ホテル、周辺情報については キャンパスページ をご覧ください。現地に行けない場合はオンラインで参加するのがお勧めです。キーノート、イノベーショントークのライブストリーミング、ブレイクアウトセッションへのアクセスなどがオンラインで体験できます。オンライン re:Invent の詳細や登録は、 登録ページ をご覧ください。 フロントエンド Web & モバイルアプリ ブレイクアウトセッション ブレイクアウトセッションとは AWS re:Invent のブレイクアウトセッションは講義形式で 60 分間行われます。ブレイクアウトセッションは AWS の専門家が講演を行い、通常最後の 10 〜 15 分間が質疑応答の時間に充てられます。ブレイクアウトセッションは録画され、イベント後にオンデマンドで視聴できるようになります。 中級 — レベル 200 FWM202 |   Fullstack AI with AWS Amplify Generative AI はフルスタック開発を変革しています。このセッションでは、AWS Amplify、Amazon Q、Amazon Bedrock がどのように連携して、Generative AI アプリの構築を合理化するかを学びます。Amplify が Amazon Bedrock によってサポートされた、インテリジェントサーチ、要約、コンテンツ生成、対話型チャットボットなどの AI 主導の機能を開発者が構築できるようにする方法を確認します。また、Amplify と Amazon Q を使用すれば、開発プロセスを加速できることも示します。 日時: 12 月 2 日 (月)  15:00 – 16:00  (PST) 場所: Mandalay Bay | Lower Level North | Islander G FWM203 |   I didn’t know AWS AppSync could do that! AWS AppSync は、アプリをクラウドのデータ、イベント、AI モデルに接続するための開発者向けの管理サービスです。もはや GraphQL API サービスだけではなく、AWS AppSync を使えば、サーバーレス WebSockets を利用してリアルタイムイベント API を作成したり、Amazon Bedrock への安全なアプリケーションアクセスを簡素化するための AI ゲートウェイを構築したりできます。今年リリースされた AWS AppSync の新機能についてお話しますので、ぜひご参加ください。 日時:  12 月 2 日 (月) 13:30 – 14:30 (PST) 場所: Mandalay Bay | Lower Level North | South Pacific E | Purple FWM204 | Optimizing the world’s top apps: How Meta tests using AWS Device Farm このセッションでは、AWS Device Farm を使ってリアルデバイスでのテストを大規模に実行することで、モバイルアプリおよび Web アプリの品質を向上させる方法を学びます。主要なソーシャルメディア企業である Meta から、同社が Device Farm を活用してモバイルアプリのテストプロセスの合理化、モバイルアプリと SDK の品質向上、クラウド上のリアルデバイスでの自動テストと手動テストの実行、課題の特定と修正の迅速化、更新リリースの頻度向上を図っている事例を聞いていただけます。 日時: 12 月 4 日 (水) 10:30 – 11:30 (PST) 場所: MGM Grand | Level 1 | Grand 119 FWM205 | Startup to enterprise: Build frontend and fullstack apps that scale AWS Amplify は、プロの開発チームに対して、エンドツーエンドの経験と検証済みのパターンを提供し、AWS インフラストラクチャの速度と信頼性を活かしてプロダクティビティを加速し、構築することを可能にします。組織の成長を妨げることのないアプリを構築するために、Amplify に組み込まれたこれらのパターンと、CDK で AWS バックエンドをカスタマイズする Amplify の柔軟性を活用する方法を学びましょう。このセッションでは、実際のシナリオのウォークスルーを行い、AWS 上でセキュアで拡張性があり、クラウドに接続されたアプリケーションを構築、デプロイ、ホストすることをこれまでにないほど容易にする、Amplify の新しいエンタープライズ重視の機能をご紹介します。 日時: 12 月 4 日 (水) 16:30 – 17:30 (PST) 場所: MGM Grand | Level 1 | Grand 116 上級（レベル 300 ） FWM302 | Real-time event patterns with WebSockets and AWS AppSync AWS AppSync は、開発者がリアルタイムデータの更新やイベント (ライブスポーツのスコアや統計、グループチャットのメッセージ、価格、または位置情報やスケジュールの更新など) を消費するアプリケーションを構築するのを容易にします。AWS AppSync の管理対象の WebSocket チャネルを使えば、数百万人のユーザーに接続して数十億単位のメッセージを配信するのを簡単にスケーリングできます。このセッションでは、PGA ツアーなどの組織が、AWS AppSync を利用して実時間のイベント更新をアプリユーザーに配信する方法を学びます。さらに、拡張されたフィルタリングオプションや Amazon EventBridge との組み込み統合などの新機能の概要も説明します。 日時:  12 月 2 日 (月) 8:30 – 9:30 (PST) 場所: MGM Grand | Level 3 | Chairmans 370 FWM310 | Build an AI gateway for Amazon Bedrock with AWS AppSync 生成 AI をアプリケーションに統合することは複雑で、開発者は AI バックエンドにアクセスする際に、複雑な権限、公開された認証情報、ID 管理の課題に対処する必要があることが多くあります。このセッションでは、AWS AppSync を使用して Amazon Bedrock などの AI バックエンドとの統合を簡素化する方法、ユースケースに合わせてクエリをカスタマイズする方法、本番利用可能な API をデプロイするためのセキュリティ機能を活用する方法、生成 AI リソースへのアクセスを制御する方法について説明します。これは、同期および非同期のユースケースの両方をカバーします。 日時: 12 月 2 日 (月) 10 :30 – 11:30 (PST) 場所: Wynn | Level 1 | Lafite 4 | Content Hub | Orange Screen FWM311 | What’s new in AWS for frontend developers AWS Amplify は、フロントエンド Web およびモバイル開発者が最小限のクラウドの専門知識で数時間でフルスタックアプリケーションを構築できるようにしています。このセッションでは、認証、データ、ストレージで簡単にバックエンドを構成する方法、フロントエンド UI を作成する方法、Next.js で サーバーサイドレンダリングの Web アプリをホストする方法など、Amplify の機能を紹介します。開発者とチームがイノベーションのペースを加速し、データを活用して差別化されたアプリケーション体験を構築し、リモートワーク環境でも個々のエンジニアが開発しやすくなる、興味深い新機能についても学びます。 日時: 12 月 4 日 (水) 13:30 – 14:30 (PST) 場所: MGM Grand | Level 1 | Grand 122 DEV304 | Build a cloud-powered cross-platform app with AWS Amplify AWS Amplify は、AWS 上でフルスタックアプリケーションを構築するための開発者体験を再構想しました。Amplify の次世代バックエンド構築体験では、すべての フロントエンドとバックエンド定義を TypeScript で記述することができます。これにより、コーディング中にスキーマの検証、入力補完、エンドツーエンドの型付けが可能になります。また、開発者ごとのクラウドサンドボックスや他の多くのツールや機能も利用できます。このセッションでは、AWS Amplify の次世代、バックエンド構築方法、AWS CDK を利用した Amazon Bedrock などの生成 AI サービスを含む他の AWS サービス拡張方法について学びます。 日時: 12 月 5 日 (木) 13:00 – 14:00 (PST) 場所: Mandalay Bay | Level 2 South | Mandalay Bay Ballroom L | Content Hub | Orange Screen DEV305 | Building an educational startup on AWS: A heroic journey クラウドの世界を旅するふたりの AWS の英雄の物語をご覧ください。目標は、AWS で AWS の教育プラットフォームを構築してデプロイすることです。彼らは、Amazon Cognito での MFA の開発、AWS Amplify の利用、AWS WAF によるセキュリティ強化、Amazon DynamoDB でのユーザー持続化、Amazon API Gateway での要求処理、AWS Lambda と Powertools を使ったビルドなど、さまざまな丘や谷を案内します。冒険家たちがその任務に成功したのか、それとも最後に全然違うところに辿り着いて諦めてしまったのか、ぜひお確かめください。 日時: 12 月 3 日 (火) 13:00 – 14:00 (PST) 場所: MGM Grand | Level 1 | Grand 120 フロントエンド Web & モバイルチョークトーク チョークトークとは チョークトークは小人数を対象とした、非常にインタラクティブなセッションです。専門家が議論の流れに応じてデジタルホワイトボードに問題と解決策を説明していきます。各セッションでは、最初に AWS の専門家が 10 ~ 15 分の短い講義を行い、その後 45 ~ 50 分の質疑応答セッションで参加者との議論が行われます。 中級者向け FWM201 | Deliver reliable generative AI mobile apps: A testing architecture このチョーク・トークでは、AWS Device Farm の力を活用して、モバイルテストの戦略を変革する方法を見つけましょう。Adobe は、Device Farm を使って、AI 対応アプリをテストするための標準化されスケーラブルなモバイルテストフレームワークを構築する方法を共有します。次のことを学びましょう。物理デバイスを所有または管理しなくても、さまざまな iOS と Android デバイス間でテストを実行できる方法。テスト パイプラインに新しいアプリを導入する時間を短縮する方法。アプリの機能、パフォーマンス、リソース使用状況についての洞察を得る方法。 日時: 12 月 4 日 (水) 17:30 – 18:30 (PST) 場所: MGM Grand | Level 1 | Boulevard 167 FWM206 | Accelerate frontend delivery with AWS Amplify Hosting このセッションでは、AWS Amplify Hosting がいかに高パフォーマンス、信頼性、スケーラビリティの高い Web 体験をより早く提供するためのサポートを行えるかを探ります。Amplify Hosting は、Next.js などの一般的な開発フレームワークをサポートする、完全マネージド型のホスティングサービスです。CI/CD 機能、フレームワークとの統合、スケーラブルなインフラストラクチャを活用して、品質を落とすことなく Web アプリケーションを迅速に提供できます。組織がイノベーションをより早く行えるよう、モダン Web 開発のベストプラクティスと手法について説明します。AWS Amplify Hosting を使用して、静的レンダリングやサーバーサイドレンダリングのフロントエンドアプリを手軽に構築、デプロイ、スケーリングするための知識を得られます。 最初のセッション 日時: 12 月 2 日 (月) 9:00 – 10:00 (PST) 場所: Wynn | Convention Promenade | Lafleur 2 リピート 日時: 12 月 4 日 (水) 8:30 – 9:30 (PST) 場所: Caesars Forum | Level 1 | Academy 411 レベル 300 — 上級者向け FWM301 | Go from idea to AI-powered app in minutes with AWS Amplify AWS Amplify は最近、AWS 上で本番環境に向けたアプリケーションを構築するための完全な TypeScript 機能を備えた第 2 世代の開発者エクスペリエンスを発表しました。第 2 世代は AWS Cloud Development Kit (AWS CDK) 上に構築されており、生成 AI ユースケースのための Amazon Bedrock を含む 200 を超える AWS サービスをすべて Amplify アプリケーションに追加できるようになりました。このチョークトークでは、AWS CDK と Amazon Bedrock を使って、次世代の革新的なアプリケーションエクスペリエンスを作成するための戦略について議論します。Amplify のフルスタック TypeScript 機能を拡張する方法についても扱います。 最初のセッション 日時: 12 月 2 日 (月) 10:30 – 11:30 (PST) 場所: Wynn | Convention Promenade | Latour 5 リピート 日時: 12 月 4 日 (水) 9:00 – 10:00  (PST) 場所: Caesars Forum | Level 1 | Forum 126 FWM314 | AWS Amplify: Integrating data sources, authentication & AWS services AWS Amplify の最新のアップデートで、フルスタックアプリケーションの機能を拡張しましょう。このチョークトークでは、Amplify が幅広い既存のデータソース、認証プロバイダー、AWS インフラストラクチャとシームレスに統合できることを探ります。Amplify が持つデータモデリングと API 生成機能を活用し、Amplify で開発したアプリケーションを PostgreSQL や MySQL データベースに接続することができます。任意の OpenID Connect (OIDC) または SAML プロバイダーでユーザー認証を行うこともできます。AWS CDK を使えば、Amazon S3 バケットや Amazon DynamoDB テーブルなどの Amplify リソースをカスタマイズすることができ、プロジェクトにカスタム AWS リソースを追加することもできます。 日時: 12 月 2 日 (月) 16:30 – 17:30 (PST) 場所: Caesars Forum | Level 1 | Forum 126 FWM315 | Build a BFF API layer for your AI models, data, and events AWS AppSync を使えば、複数のデータベース、マイクロサービス、イベント、AI モデルを 1 つの backend-for-frontend (BFF) endpoint に統合できます。このチョークトークでは、AWS AppSync を使って Amazon Bedrock、Amazon SageMaker、サードパーティのモデルの使用を管理・調整する単一の API エンドポイントを作成する方法に焦点を当てています。これにより、アプリケーション開発者はユースケースに合わせて適切なモデルを簡単にアクセスでき、新しいモデルが登場した際にもすばやく切り替えられます。また、同じエンドポイントを拡張してエンタープライズデータやイベントを AI のプロンプトとレスポンスに取り入れる方法も学べます。 日時: 12 月 4 日 (水) 15:00 – 16:00 (PST) 場所: Caesars Forum | Level 1 | Alliance 305 FWM316 | Fullstack deployment strategies for teams of all sizes AWS Amplify は最近、Gen 2 の開発者体験を発表し、AWS で本番環境に対応したアプリケーションを構築するための、TypeScript を全面的にサポートしたフルスタック開発の機能を提供しています。Gen 2 は AWS CDK 上に構築されており、Amplify アプリに 200 以上の AWS サービスを追加できるようになっており、生成 AI 用途では Amazon Bedrock を追加できます。このチョークトークセッションでは、異なる Git 戦略、モノレポとマルチレポ、複数の AWS アカウントで Amplily フルスタックの TypeScript 機能を拡張する戦略について議論します。 日時: 12 月 4 日 (水) 12:00 – 13:00 (PST) 場所: Caesars Forum | Level 1 | Alliance 305 フロントエンド Web & モバイルワークショップ ワークショップとは ワークショップは、AWS のチームが設計したハンズオン形式のセッションです。ワークショップの目的は、ビジネスの問題を解決するのに役立つ、実践的なスキル、手法、コンセプトを教えたり、紹介したりすることです。 上級編 FWM303 | Build server-side rendered (SSR) apps with AWS Amplify and Next.js Next.js は フロントエンドおよびフルスタック Web 開発者に最適な、サーバーサイドレンダリング (SSR) React フレームワークとして勢いを増しています。このワークショップに参加し、新しい AWS Amplify Gen 2 の開発体験で、Next.js アプリケーションを開発およびデプロイする方法を学んでください。ラップトップをご持参ください。 最初のセッション 日時: 12 月 4 日 (水) 16:00 – 18:00 (PST) 場所: MGM Grand | Level 1 | Grand 111 リピート 日時: 12 月 5 日 (木) 15:00 – 17:00 (PST) 場所: MGM Grand | Level 3 | Premier 312 FWM306 | Building GraphQL APIs with AWS AppSync 本ワークショップでは、GraphQL API の開発を簡単にする、フルマネージドサービスの AWS AppSync の機能について学びます。AWS AppSync が Amazon DynamoDB、Amazon Bedrock、AWS Lambda などのデータソースへのセキュアな接続の重荷を処理する方法を学びます。ラップトップをご持参ください。 日時: 12 月 2 日 (月) 15:30 –  17:30 (PST) 場所: Caesars Forum | Level 1 | Summit 216 FWM308 | Go from idea to app in hours using AWS Amplify and Amazon Q Developer AWS Amplify と Amazon Q Developer を使えば、フルスタックアプリをアイデアから現実のものへと、より早く作り上げることができます。このワークショップでは、AWS Amplify を使ってフルスタックアプリを構築・デプロイし、Amazon Q Developer がどのようにソフトウェア開発ライフサイクル全体を加速するかを確認します。このワークショップを終えると、クラウドに接続されたアプリケーションの構築と立ち上げ方法を習得できます。ラップトップをご持参ください。 最初のセッション 日時: 12 月 4 日 (水) 8:30 – 10:30 (PST) 場所: MGM Grand | Level 1 | Grand 113 リピート 日時: 12 月 5 日 (木) 12:00 – 14:00 (PST) 場所: MGM Grand | Level 3 | Premier 312 FWM309 | Build real-time applications with AWS Amplify & AWS AppSync WebSockets リアルタイムデータを利用してユーザーエンゲージメントを高めるアプリケーションの作成方法を学びます。このワークショップでは、ライブスコア更新とグループチャット機能を備えたマルチプレイヤー形式の簡単なクイズゲームアプリを構築します。AWS Amplify を使用してフロントエンドアプリケーションを AWS AppSync WebSockets で構築されたサーバーレスバックエンドに接続します。ラップトップをご持参ください。 日時: 12 月 4 日 (水) 12:30 – 14:30 (PST) 会場: Wynn | Upper Convention Promenade | Cristal 1 FWM313 | Test your web and mobile applications with AWS Device Farm AWS Device Farm は、デスクトップブラウザやリアルモバイルデバイスの広範な種類の上で、アプリケーションをテストできるサービスです。このサービスを利用することで、テストインフラを自前で用意したり管理したりすることなく、幅広いデスクトップブラウザや実際のモバイルデバイスでウェブアプリケーションやモバイルアプリケーションをテストでき、アプリケーションの品質向上に役立ちます。このワークショップでは、ソフトウェアエンジニア、品質保証エンジニア、ソフトウェアテスター、プラットフォームエンジニア、アーキテクトの方々に、AWS クラウドでホストされたアプリケーションをテストするための Device Farm の使い方をハンズオンで学んでいただきます。ラップトップをご持参ください。 日時: 12 月 2 日 (月) 8:00 – 10:00 (PST) 場所: MGM Grand | Level 3 | Premier 312 ENU314 | Bring AWS IoT SiteWise visualizations into web applications AWS IoT SiteWise Monitor を使用すると、AWS IoT SiteWise で監視するアセットの測定値を視覚化するためのポータルやダッシュボードを構築できます。AWS IoT Application Kit は、産業用 IoT Web アプリケーションを構築するための開発ライブラリで、AWS IoT SiteWise や AWS IoT TwinMaker からデータを取得するのに役立ち、フロントエンド用のコンポーネントやユーティリティを提供します。このワークショップでは、AWS Amplify と React で Web アプリケーションを構築し、AWS IoT Application Kit のコンポーネントを使用して AWS IoT SiteWise に接続し、テレメトリデータのライブ視覚化をアプリケーションに組み込みます。ラップトップをご持参ください。 日時: 12 月 2 日 (月) 8:30 – 10:30 (PST) 場所: Wynn | Convention Promenade | Margaux 2 ビルダーセッションとは これらの 60 分のグループセッションは AWS のエキスパートが主導し、AWS での構築に向けたインタラクティブな学習体験を提供します。ビルダーセッションは、質問を歓迎する実践的な体験を作ることを目的としています。 上級者向け 300 レベル FWM304 | Build generative AI applications with full-stack TypeScript AWS Amplify の TypeScript ベースの開発者体験を使って、パワフルな生成 AI Web アプリケーションを構築しましょう。このハンズオンビルダーのセッションでは、インテリジェントサーチ、要約、コンテンツ生成、対話型 AI アシスタントなどの AI 駆動型の機能を構築します。データ管理とユーザー認証を含むコアとなるアプリケーションコンポーネントとの統合方法を学びます。セッションの最後には、完成したアプリケーションをクラウドにデプロイし、フルスタック AI アプリケーションの開発と起動の実践的な経験を得ることができます。ラップトップをご持参ください。 最初のセッション 日時 : 12 月 2 日 (月) 9:00 – 10:00 (PST) 場所 : Caesars Forum | Level 1 | Alliance 311 リピート #1 日時: 12 月 5 日 (木) 11:30 – 12:30 (PST) 場所: Mandalay Bay | Level 2 South | Surf E リピート #2 日時: 12 月 5 日 (木) 15:30 – 16:30 (PST) 場所: Mandalay Bay | Level 2 South | Surf B FWM305 | Best practices for creating and testing cross-platform apps on AWS 異なるコードベースを維持する手間をかけずに、Android、iOS、Web アプリケーションの開発方法を学びます。AWS Amplify の React Native ライブラリを使用し、クラウドサポートされた機能豊富なアプリケーションを作成します。認証、API およびデータの連携、生成 AI、メディア/ファイル格納などの機能を追加する方法を学びます。また、AWS Device Farm でアプリケーションをテストします。ラップトップをご持参ください。 最初のセッション 日時: 12 月 2 日 (月) 9:00 – 10:00 (PST) 場所: Caesars Forum | Level 1 | Alliance 311 リピート #1 日時: 12 月 3 日 (火) 12:00 – 13:00 場所: Caesars Forum | Level 1 | Summit 232 | Content Hub | Builder’s 2 リピート #2 日時: 12 月 5 日 (木) 14:00 – 15:00 (PST) 場所: Mandalay Bay | Level 2 South | Surf B NTA308 | Build a secure GraphQL with AWS AppSync このセッションでは、AWS Amplify Studio と AWS AppSync を使用して、セキュアでスケーラブルな GraphQL API を構築する方法を学びます。まず GraphQL ベースのアーキテクチャの利点とアプリケーション開発の簡素化にどのように役立つかを確認します。次にハンズオンセッションで、参加者自身の GraphQL API の作成、認証と認可の設定、プロダクション環境へのデプロイを行います。ラップトップをご持参ください。 最初のセッション 日時: 12 月 2 日 (月) 13:00 – 14:00 (PST) 場所: Caesars Forum | Level 1 | Alliance 315 リピート 日時: 12 月 3 日 (火) 17:30 – 18:30 (PST) 場所: Caesars Forum | Level 1 | Summit 232 | Content Hub | Builder’s 1 ARC301 | Rapidly build a generative AI-based full-stack application on AWS フルスタックアプリケーションを構築するには、複数のコンポーネントと、幅広い技術スキルとツールが必要です。これは経験豊富な開発者にとっても非常に困難で時間がかかる作業です。このビルダーセッションでは、生成 AI ベースのデジタルトレーニングプラットフォームを迅速に構築する戦略を探ります。新しいコードファーストの開発者体験 AWS Amplify Gen 2 とオープンソースのデザインライブラリ Cloudscape を組み合わせ、フルスタックアプリケーションを迅速に構築してデプロイします。Amazon Bedrock の優れた機能を使用して、プラットフォームにアップロードされたコンテンツの概要を生成します。実用的な e-ラーニングプラットフォームの構築とデプロイ方法を学びます。ラップトップをご持参ください。 日時: 12 月 2 日 (月) 14:30 – 15:30 (PST) 場所: Caesars Forum | Level 1 | Alliance 315 ライトニングトークとは ライトニングトークは、ステージ上で行われる短い 20 分間のデモです。 AIM246 | Securing AI-driven applications with Auth0 by Okta and Amazon Bedrock 今日のデジタル環境では、アプリケーションのセキュリティ確保が不可欠です。この講演では、開発者が Okta の Auth0 の ID 管理ソリューションを Amazon Bedrock と併用して、セキュアなアプリケーションを構築、スケーリングする方法を解説します。Auth0 の認証、認可、ユーザー管理機能を Amazon Bedrock のセキュア基盤にどのように統合するかについて説明します。また、AWS Amplify がフロントエンドとバックエンド サービスを堅牢な ID 管理機能と統合して開発を簡素化する方法についても触れます。クラウド上で効率的にモダンでセキュアなアプリケーションを構築するための、主要なユースケース、ベストプラクティス、技術的な統合について実践的な知識を得ることができます。このセッションは AWS のパートナーである Okta 様にご登壇いただきます。 日時: 12 月 3 日 (火)  10:30 – 10:50 (PST) 場所: Venetian | Hall B | Expo | Theater 1 コードトークとは コードトークは 60 分間の、ハイレベルなインタラクティブディスカッションで、実際にコーディングを行います。参加者は、スピーカーのアプローチについて質問したり、掘り下げたりすることが推奨されています。 Level 300 — 説明セッション FWM312 | Best practices for building full stack multi-tenant apps on AWS スケーラブルな、マルチテナントのアプリケーションを開発するのは複雑です。このコードトークでは、AWS Amplify と AWS AppSync を使用して、セキュリティが確保され、パフォーマンスが高いマルチテナントのフルスタック環境を簡単に構築する方法を学びます。Amplify のフロントエンドホスティングと AWS AppSync の管理型 GraphQL サービスを活用し、AWS 上でマルチテナント基盤を設計するためのベストプラクティスを発見できます。ライブデモと例を通して、Amplify と AWS AppSync が協調して、企業レベルのマルチテナント環境の提供を早めるのを確認できます。スケーラブルなマルチテナントアプリケーションを構築し、お客様のニーズを満たす知識を得られます。 時間: 12 月 3 日 (火) 16:30 – 17:30 (PST) 場所: Wynn | Convention Promenade | Lafite 2 最新情報を取得するには? フロントエンド Web およびモバイルアプリ開発者の最新情報を入手するには、 X をフォローしたり、 Discord に参加したり、 re:Invent   Web サイトでセッションを確認したりしてください。 本記事は「 The frontend web and mobile app developer’s guide to AWS re:Invent 2024 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

このブログは 2024 年 10 月 30 日に Jay Horne (Principal Solutions Architect) と Randy Seamans (Principal Solutions Architect) によって共同執筆された内容を日本語化したものです。原文は こちら を参照してください。 過去 20 年以上にわたり、VMware などの市販のコンピューティング仮想化ソリューションは、コストの削減、効率性の向上、管理タスクの簡素化、オンプレミスの柔軟性の向上に使用される強力なツールとなっています。時間の経過とともに、ほとんどのクラウドプロバイダーは無数のクラウドネイティブサービスへの直接アクセスを提供しながら、従来のオンプレミス仮想化スイートで利用できる機能と同等かそれ以上の高度なストレージ、効率性、管理機能をハイパーバイザーに加えてきました。並行して、Broadcom による VMware の最近の買収により、クラウドとオンプレミスの両方で VMware の販売とライセンスの方法に多くの変更がもたらされました。代わりのハイパーバイザーを検討している場合、幸いなことに、関連するストレージを同時に移行しながらあるハイパーバイザーから別のハイパーバイザーへ移動することは、もはや危険で途方もない作業ではありません。 本日、 図 1 に示すように、既存の VMware VM (仮想マシン) とストレージを、あらゆるクラウドベースの VMware ソリューションまたはあらゆるオンプレミスの VMware 環境から、 Amazon Elastic Compute Cloud (Amazon EC2) と Amazon Elastic Block Store (Amazon EBS) および Amazon FSx for NetApp ONTAP の組み合わせに移行するための、シームレスで自動化されたソリューションを紹介します。移行プロセスは、カットオーバーを完了するための短時間の停止まで中断されることなく実行され、ソース上のあらゆるタイプのブロックデバイスをサポートします。最終的に、仮想化環境はハイパーバイザーとストレージデバイスの両方にわたって真に身軽で俊敏になります。このソリューションがどのように実現されるかみていきましょう。 図 1: VM とストレージを自動移行するソリューションのコンセプト 直接的な移行 これまでにクロスプラットフォームの大規模な仮想化移行を行ったことがあるなら、移行プロジェクトの企画を管理するために必要な労力、それに伴うリスク、複雑さをご存知でしょう。AWS パートナーの Cirrus Data Solutions は最近、Amazon EC2 ハイパーバイザー、Amazon EBS、Amazon FSx NetApp for ONTAP ブロックのサポートを Cirrus Migrate Cloud (CMC) に追加しました。Cirrus は、 図 2 に示すように、エンタープライズ級の移行を直接行っています。MigrateOPs によるワンクリックの大規模なエンタープライズ移行をぜひご検討ください。 図 2: Cirrus Migrate Cloud のアーキテクチャ MigrateOPs は、YAML ドリブン (migration-as-code: 移行のコード化) な移行オーケストレーションツールです。これは理論上は十分なものであり、こちらの デモビデオ では、Windows と Linux の VMware VM とそのゲストストレージを AWS にライブ移行する様子を公開しています。デモでは移行された VM は 2 つだけですが、MigrateOPs は大規模なエンタープライズ環境をオーケストレーションできるため、人的リスク要因やデータ損失や移行失敗となるその他の原因を排除できます。 皆さんが何を考えているかはわかります。ストレージ環境はもう少し複雑かもしれません。ここで、オンプレミス環境のデータストアに現在使用している可能性のあるストレージプロトコルを見てみましょう。最新のブロックプロトコル (iSCSI、SCSI over Fibre Channel、NVMe over Fibre Channel、NVMe over TCP) や NFS などが考えられます。ここで紹介するアプローチでは、 表 1 に示すように、前述のプロトコルの任意の組み合わせから自動的に移行できます。 表 1: 移行元ストレージ、AWS 上の移行先ターゲットストレージ、移行ツール 右端の列に示されているように、 Amazon Machine Image (AMI) を使用して EC2 インスタンスを起動するには、Amazon EBS が必要です。ただし、前の表では、特定のワークロードに最適なブロックサービスがどれであるかに応じて、ブロックデータを FSx for ONTAP ブロックサービスまたは Amazon EBS に移行できます。一部のアプリケーションは Amazon EBS に最適ですが、マルチ アベイラビリティ ゾーン (AZ) とシングル AZ のサポート、大規模なスケールアップとスケールアウトのパフォーマンス機能、レプリケーション、シンクローン、およびデータ削減テクノロジが必要な場合は、FSx for NetApp のブロックストレージを検討する必要があります。CMC は、ベストプラクティスに従いながらパフォーマンスと容量に合わせて AWS ブロックストレージを構成することで、移行元ストレージに合わせて FSx for ONTAP ブロックストレージや Amazon EBS を自動的に構築/構成し移行をシームレスに実行します。実際、Amazon EBS のデプロイメントも対象としている場合、このソリューションを使用できます。 上の表の最後の 2 行は、移行元ストレージが VM に共有をプロビジョニングしていることを示しています (データストアの VMDK ではありません)。この場合、ブロックベースの移行ツールは OS ボリュームのみを移行でき、NFS に基づくデータ共有は移行できません。移行元 NFS ストレージが NetApp ONTAP で、移行先が AWS の FSx for ONTAP である場合は、 NetApp SnapMirror タスクを Cirrus の 自動移行に組み込みます。移行元 NFS データストアが NetApp ベースでない場合は、 AWS DataSync を使用して適切なファイルを FSx for ONTAP のファイルマウントポイントに移動し、最終的な DataSync 同期ポイントを Cirrus の自動化された移行タスクに組み込むことができます。 これでストレージをスムーズに移行できたので、次は AMI を使用する Amazon EC2 ハイパーバイザー で使用できるように VMware VMDK ファイルをどのように変換すればよいでしょうか。従来、ストレージの移行には EC2 Import/Export サービスと別のツールを使用してきました。しかし、ストレージと VM の移行を 1 つのユニットとして網羅する完全なソリューションの提供をお約束しました。VMware の vMotion ホットマイグレーションに精通している場合、Cirrus のアプローチは同様のパスを取ります。つまり、VM の実行を継続しながら、基盤となる OS ディスクをビットごとに移行します。OS ディスクとその他の補助ストレージがバックグラウンドで移行されたら、VM を停止し、最終的な同期を実行して EC2 インスタンスに切り替えます。何よりも優れているのは、vMotion とは異なり、この移行環境は真のクロスプラットフォームであるため、VM をハイパーバイザータイプ間で確実に移動できることです。移行の一環として、CMC は、FSx for ONTAP ブロックデバイスに必要な正しいマルチパスおよび iSCSI 構成に各 VM を自動的に修正します。たとえば、VM が新しい自動プロビジョニングされた適合した FSx for NetApp ONTAP ブロックデバイスにアクセスできるようにアクセスグループを構築します。この高度な自動化により、組織は移行方法ではなく、移行対象に集中できます。もう 1 つ詳細があります。移行中の VM とストレージの両方がスナップショットによって保護され、必要に応じて移行をシームレスにロールバックできます。 おめでとうございます。データと VM を手軽で俊敏にする方法を学びました。それだけでなく、将来 AWS から移行することに決めた場合も、同じように直接移行でき、 離脱に伴うペナルティや料金は一切発生しません 。AWS へようこそ！ クリーンアップ AWS への移行が完了したら、Cirrus Migration ソフトウェアを完全にアンインストールできます。実際のワークロードを移行するのではなく、AWS アカウントで移行をテストする場合は、移行したインスタンスと関連する Amazon FSx for NetApp ONTAP リソースを必ず削除してください。最後に、概念実証 (PoC) を実行する予定がある場合は、AWS の無料利用枠と無料の Cirrus デモライセンスを使用できることを忘れないでください。 学習したこと 本日、CMC を使用して VMware VM をどこからでも Amazon EC2 および FSx for NetApp ONTAP に安全に移行する方法を学びました。他のユーザーが VMware 環境にこのオプションを選択しているさまざまな理由の詳細については、こちらの NetApp の記事 と NetApp ソリューションガイド をご覧ください。 AWS アカウント をお持ちでないが、これが組織でどのように機能するかを評価したい場合は、今すぐ AWS アカウント を利用して開始できます。AWS の Amazon FSx NetApp for ONTAP の機能に詳しくない場合は、 ユーザーガイド をご覧ください。 AWS パートナーマーケットプレイス で CMC の価格などの詳細を確認したり、 無料の 1 TB ライセンス を開始することができます。Cirrus と AWS は、複雑な VM 移行を支援する完全なターンキーソリューションも提供しています。最後に、ユーザーが 1 回限りの移行コストを排除または削減できるように、Amazon は AWS VMware Migration Accelerator を導入しました。これは、任意の VMware Cloud on AWS 環境から Amazon EC2 および FSx for ONTAP に移行した VM 1 台あたり最大 400 ドルのクレジットを提供します。既存のオンプレミス環境の場合は、Amazon EC2 および Amazon FSx for NetApp ONTAP の移行クレジットの利用可能性について AWS の担当者に確認してください。 このソリューションが意味すること 新しい時代が到来しました。もはやデータと VM はハイパーバイザー間で移動可能になり、AWS ではデータとコンピューティングを別の場所に移行する場合でも料金はかかりません。FSx for ONTAP、Amazon EBS、Amazon EC2 の高度なストレージ機能を使用することで、コスト効率の高い方法で、エンタープライズクラスの高性能な高可用性 (HA) および災害復旧 (DR) 対応環境を構築できます。VM 環境を AWS Storage と Amazon EC2 に移行する可能性を検討している組織は、この記事の著者またはお近くの AWS 担当者にお問い合わせください。AWS は、VMware 環境の包括的な評価を実行し、費用対効果が高くシームレスな移行プランを作成できます。 翻訳はネットアップ合同会社の Sr. Cloud Solutions Architect for AWS の藤原様、監修は Cloud Support Engineer の戸松が担当しました。 Jay Horne Jay Horne は、AWS のワールドワイドスペシャリスト組織における Amazon FSx for NetApp ONTAP サービスのグローバルテクニカルリーダーおよびサービス連携ソリューションアーキテクトです。テネシー州ナッシュビルを拠点とする Jay は、さまざまなクラウド、ストレージ、サーバー、ネットワークインフラストラクチャに携わった 15 年以上のエンタープライズコンサルティング経験を持っています。世界中のストレージおよびクラウドカンファレンスで頻繁に講演を行っています。 Randy Seamans Randy はストレージ業界のベテランであり、高性能ストレージ、コンピューティング (HPC)、および災害復旧を専門とする AWS のプリンシパルストレージスペシャリスト兼アドボケートです。ストレージに関する洞察や楽しみをさらに知るには、https://www.linkedin.com/in/storageperformance で彼をフォローしてください。  

この記事は、” Jumpstart your HPC journey with the AWS Parallel Computing Service getting started kit ” を翻訳したものです。 先日、AWS は ハイパフォーマンスコンピューティング の領域の革新的なサービス、 AWS Parallel Computing Service（AWS PCS）のローンチを発表 しました。AWS PCSは、インフラストラクチャの管理に煩わされることなく、HPC ワークロードの実行とスケーリングをこれまで以上に容易にする管理サービスです。気象パターンのシミュレーション、次世代車両の設計、がん治療法の探索など、あらゆる研究や革新的な取り組みを加速させるために、AWS PCS は設計されています。 AWS PCSのローンチに伴い、すぐに使いこなせるよう、豊富なリソースをご用意しました。マニュアルを読むのが好きな方、動画で学びたい方、実践的なアプローチを好む方など、様々なニーズに対応しています。 本記事では、これらのリソースをご紹介し、PCS をスムーズに始められるようサポートいたします。 1 クリックで PCS についてよく学ぶことができるリソース 最初に紹介するリソースは、最短でひらめきを得られるかもしれません。HPC Recipes Library(詳細は後述)の PCS recipe をワンクリックすると、事前に用意されたサンプル AMI をベースとした Amazon FSx for Lustre scratch filesystem、小規模な x86 インスタンスのノードグループが実装された HPC cluster を最短で試すことができます。 これが本番環境用のクラスターになるとは考えていませんが、最も早く Slurm コマンドラインを試すことができ、どういったものが最適かを見つけることができます。このレシピを使うと、わずか15分でクラスターを試しに動かすことができます。古典的な学習方法、つまり作って壊しながら学ぶことができます。 AWS PCS User Guide 他の AWS サービスと同様に、AWS PCS にも 詳細なユーザーガイド があります。このガイドは、サービスの開発に携わっているテクニカルライター、ソフトウェアエンジニア、プロダクトマネージャーによって作成されています。ガイドでは、PCS を利用するための AWS アカウントの設定方法をはじめ、用途に合ったクラスターサイズの選び方、クラスターの運用管理、PCS が他の AWS サービスとどのように連携し統合されるかなど、幅広いトピックを網羅しています。 さらに、「 Getting started with AWS PCS 」という一歩ずつ学べるチュートリアルも含まれており、PCS クラスターの基本的な構成要素（クラスターのプリミティブ、コンピュートノードグループ、キュー、外部ファイルシステムなど）について解説しています。また、シンプルながら実用的な HPC 環境を構築するための手順も詳しく説明されています。 HPC Tech Shorts 時には、単に手順を読むだけでなく、実際のデモンストレーションを見たり、より広い文脈でのサービスの利用法を聞いたりすることが役立つことがあります。 PCS の使い方をより深く理解するために、 YouTube の HPC Tech Shorts チャンネル で 2 時間以上の実践的な動画コンテンツが公開されています。現在 6 本の動画が用意されており、今後数週間から数ヶ月にわたってさらに追加される予定です。 動画コンテンツは以下の通りです。 Introducing AWS Parallel Computing Service (9分) – この動画では、PCS の位置付けを紹介し、仕組みや他の AWS サービスとの連携について概観しています。 Your first AWS PCS cluster (43分) – この動画では、ユーザーガイドの Getting started with AWS PCS チュートリアルに沿って、ステップ・バイ・ステップで解説しています。ネットワークの設定から、ストレージのプロビジョニング、クラスターの構築まで、各ステップで何をどのように行うのか、なぜそうするのか、を詳しく説明しています。この最初の２本の紹介動画を見れば、PCS の機能について良く理解でき、実際の動作も確認できるでしょう。 さらに深く掘り下げたい場合 は、PCS を用途に応じてカスタマイズする上で重要なトピックを扱う 4 本の動画があります。これらは順番に視聴することをお勧めします。 Launch templates, instance profiles, security groups, and AMIs (17分) – この動画では、PCS にどのように様々な AWS の基本的な要素が組み合わさって、HPC ジョブを実行するインスタンスに特定の機能や動作を可能にするかを紹介しています。 Configuring Elastic Fabric Adapter (EFA) and multi-NIC instances (20分) – 100 種類以上の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスタイプで EFA（Elastic Fabric Adapter）を使用して高速・低遅延のネットワーキングが可能です。中には複数のネットワークカードを搭載し、さらに高いスループットを実現するものもあります。この動画では、EFA を最大限に活用するためのPCSの設定方法を詳しく説明しています。また、気軽に試すための AWS CloudFormation テンプレートについても紹介します。 Create and use a custom AMI for AWS PCS (29分) – PCS では、カスタム AMI を利用して高度にカスタマイズされたソフトウェア環境を構築できます。この動画では、Rocky Linux 9 のベースラインイメージから始まり、 Spack を使用してユーザーランドソフトウェアを管理する AMI の作成まで、プロセスの各ステップを詳しく解説します。さらに、作成した AMI を PCS で実際に使用する方法もご紹介します。 Bring your own login node (21分) – AWS PCS にアクセスノード(ログインノード)を提供する方法は2つあります。PCS にログインインスタンスの管理を任せるか、自分でインスタンスを設定してクラスターの Slurm コントローラーに接続するかのいずれかです。この動画では、スタンドアロンの EC2 インスタンスを PCS クラスターとその共有している Lustre ファイルシステムに接続する方法を解説しています。 今後数ヶ月にわたって、このような解説動画がさらに追加される予定です。 HPC Recipes for AWS 昨年のこの時期に、 community recipe library for HPC infrastructure on AWS をリリースしました。このライブラリには、AWS で HPC を学んだり、概念実証(PoC)やデモを構築したりするのに使えるパターンや Infrastructure as code のリソースが含まれています。リリース以来、このライブラリは大きく成長し、いくつかの AWS HPC ブログ 記事で重要な役割を果たしてきました。今回、このライブラリに PCS-specific channel を追加しました。これにより、PCS に特化したレシピやリソースにアクセスしやすくなりました。 この PCS チャンネルは急速に成長しています。現時点での内容を少しご紹介すると、 Getting started with AWS PCS をサポートするレシピや、スタンドアロンのログインノードのセットアップ方法、さらには簡単な CFD 用クラスターの構築方法を示すレシピなどが含まれています。このリポジトリにあるレシピは、私たちのチュートリアルや動画で広く使用されています。 是非 HPC Recipes に注目してください（是非 GitHub でスターを付けてください）。HPC Recipesでは、PCS クラスターの運用に関する様々な側面を段階的に仕組み化する方法を紹介しています。 Next Steps AWS Parallel Computing Service (AWS PCS)は、AWS での HPC クラスターの管理を簡素化し、研究やイノベーションを加速させるために設計されています。利用し始めるための包括的なリソースを用意しました： 一歩ずつ学べるチュートリアルを含む詳細な ユーザーガイド YouTube の HPC Tech Shorts チャンネル にある 6 本の詳細な動画 PCS に特化したテンプレートを含む、順次拡大中の HPC Recipes for AWS ライブラリ これらのリソースは、ドキュメントを読むのが好きな方、デモを見るのが好きな方、実践的な例に直接取り組むのが好きな方など、さまざまな方の好みの学習スタイルに対応しています。 是非 AWS PCS を試してみて、HPC ワークフローをどのように変革できるか確かめてみてください。入門ガイドから始めるか、紹介動画を見るか、HPC Recipes の 1 つに取り組んでみてください。AWS PCS 上で HPC 環境を構築・拡張していく中で、科学的・工学的ブレークスルーを加速させる新しい方法を発見できるでしょう。 HPC の旅の次のステップに進む準備はできたでしょうか。 AWS Parallel Computing Serviceの製品ページ にアクセスして、詳細を確認し、今すぐ始めましょう。 試してみて、感想を ask-hpc@amazon.com までお聞かせください。AWS PCS でどんなことを成し遂げられるか、楽しみにしています。 本ブログ記事は、ソリューションアーキテクトの池田が翻訳しました。原文は こちら です Matt Vaughn Matt Vaughn は、HPC および科学計算分野の Principal Developer Advocate です。ライフサイエンスのバックグラウンドを持ち、長期的に利用してくださるユーザーのために使いやすい HPC やクラウドシステムの構築に携わってきました。仕事以外の時間は、絵を描いたり、読書をしたり、世界中を旅したり、近くにいる犬と遊んだりして過ごしています。 Brendan Bouffler Brendan Bouffler は、AWS の HPC エンジニアリング部門で Developer Relations の責任者を務めています。これまで、あらゆる環境で数百もの HPC システムの設計と構築に携わってきました。クラウドが、世界を変える発見をもたらすために全世界の研究者やエンジニアが必要とする卓越したツールになることを確信し、AWS に入社しました。 物理学の学位を持つブレンダンは、自転車にまつわる物理法則のを実験的に検証することに興味を持っています。この趣味が原因で、しばしば入院することになっています。

お客様は、 Amazon Elastic Compute Cloud (Amazon EC2) を使用して、ウェブホスティング、ビッグデータ処理、ハイパフォーマンスコンピューティング (HPC)、仮想デスクトップ、ライブイベントストリーミング、データベースなど、考え得るあらゆるタイプのワークロードを実行しています。これらのワークロードの中には非常に重要なものがあり、お客様はキャパシティを予約する機能を求めていました。 お客様が柔軟にキャパシティを予約できるようにするために、2018 年に EC2 オンデマンドキャパシティ予約 (ODCR) をリリースしました。それ以来、お客様はキャパシティ予約 (CR) を使用して、消費者向けウェブサイトのホスティング、ライブスポーツイベントのストリーミング、金融取引の処理などの重要なアプリケーションを実行してきました。 11 月 25 日、CR を使用して将来のワークロードのためにキャパシティを取得するための機能を発表しました。多くのお客様は、製品のリリースまたは大規模な移行などのイベントや、サイバーマンデーやディワリなどの年末セールイベントを予定しています。これらのイベントは重要であり、お客様は必要なときに必要な場所でキャパシティが確実に使用できる状態にしておきたいと考えています。 CR はお客様がこれらのイベントのためにキャパシティを予約するのに役立ちましたが、ジャストインタイムでしか利用できませんでした。そのため、お客様は事前にキャパシティをプロビジョニングして料金を支払うか、またはイベントの開始時に CR をジャストインタイムでプロビジョニングするように正確に計画する必要がありました。 今回の発表により、最大 120 日前まで CR を計画してスケジュールできるようになりました。使用を開始するには、必要なキャパシティ、開始日、提供の詳細設定、キャパシティ予約を使用することをコミットする最小期間を指定します。キャパシティ予約のスケジュールに前払い料金はかかりません。Amazon EC2 がリクエストを評価して承認すると、開始日に予約がアクティブ化され、お客様はそれを使用してすぐにインスタンスを起動できます。 将来の日付のキャパシティ予約の開始方法 将来の日付のキャパシティを予約するには、 Amazon EC2 コンソール で [キャパシティ予約] 、 [オンデマンドキャパシティ予約を作成] 、 [使用を開始] の順に選択します。 キャパシティ予約を作成するには、インスタンスタイプ、プラットフォーム、アベイラビリティーゾーン、プラットフォーム、テナンシー、およびリクエストするインスタンスの数を指定します。 [キャパシティ予約の詳細] セクションで、 [キャパシティ予約の開始] オプションの [将来の日付] を選択し、開始日とコミットメント期間を選択します。 キャパシティ予約を特定の時刻に終了したり、手動で終了したりすることもできます。 [手動] を選択した場合、予約に終了日はありません。手動でキャンセルするまで、アカウントでアクティブなままになり、引き続き課金されます。このキャパシティを予約するには、 [作成] を選択します。 キャパシティリクエストを作成すると、ダッシュボードに [評価中] ステータスで表示されます。この状態になっている期間中、AWS システムはリクエストがサポート可能かどうかを判断します。これは通常 5 日以内に完了します。リクエストがサポート可能であるとシステムが判断すると、ステータスは [スケジュール済み] に変更されます。まれに、リクエストがサポートされない場合があります。 スケジュールされた日付に、キャパシティ予約は [アクティブ] 状態に変わり、インスタンスの合計数はリクエストされた数まで増加し、インスタンスをすぐに起動できます。 アクティブ化後、少なくともコミットメント期間中は予約を保持する必要があります。コミットメント期間が経過した後は、必要に応じて引き続き予約を保持して使用することも、不要になった場合はキャンセルすることもできます。 知っておくべきこと 将来の日付の CR について知っておくべきことをいくつかご紹介します。 評価 – Amazon EC2 はリクエストを評価する際に複数の要素を考慮します。Amazon EC2 は、予測される供給量に加えて、キャパシティを保持する予定の期間、開始日からどの程度早期にキャパシティ予約を作成するか、およびリクエストの規模を考慮します。Amazon EC2 がお客様のリクエストをより良くサポートできるようにするには、開始日の少なくとも 56 日 (8 週間) 前に予約を作成してください。C、M、R、T、I インスタンスタイプについてのみ、少なくとも 100 vCPU のリクエストを送信する必要があります。ほとんどのリクエストで推奨される最小コミットメントは 14 日間です。 通知 – コンソールまたは Amazon EventBridge を通じてリクエストのステータスをモニタリングすることをお勧めします。これらの通知を使用して、オートメーションをトリガーしたり、E メールまたはテキスト更新を送信したりできます。詳細については、「Amazon EventBridge ユーザーガイド」の「 Amazon EventBridge を使用してイベントが発生したときに E メールを送信する 」にアクセスしてください。 料金 – 将来の日付のキャパシティ予約は、通常の CR と同様に課金されます。リザーブドキャパシティでインスタンスを実行するかどうかにかかわらず、同等のオンデマンド料金が課金されます。例えば、20 個のインスタンスの将来の日付の CR を作成し、15 個のインスタンスを実行した場合、最小期間を含む予約内のアクティブなインスタンス 15 個と未使用のインスタンス 5 個について課金されます。Savings Plans は、未使用の予約と予約で実行されているインスタンスの両方に適用されます。詳細については、「Amazon EC2 ユーザーガイド」の「 キャパシティ予約の料金と請求 」にアクセスしてください。 今すぐご利用いただけます 将来の日付の EC2 キャパシティ予約は、Amazon EC2 キャパシティ予約が利用可能なすべての AWS リージョン で 11 月 25 日からご利用いただけます。 Amazon EC2 コンソール で Amazon EC2 キャパシティ予約をお試しください。詳細については、「Amazon EC2 ユーザーガイド」の「 オンデマンドキャパシティ予約 」にアクセスし、 AWS re:Post for Amazon EC2 または通常の AWS サポートの連絡先を通じてフィードバックを送信してください。 – Channy 原文は こちら です。

2024 年 7 月 5 日に開催された「第19回情報危機管理コンテスト」決勝戦にて AWS 賞を受賞したチーム GH05TBUSTERS (ゴーストバスターズ) の皆様にインタビューを行いました。 今回の情報危機管理コンテストは 2 部制になり、前半は AWS 上に構築された Web サーバ, CDN, WAF を舞台にして行われました。情報危機管理コンテストは、参加チームは発生した事象について調査を行い、コンテスト主催者が用意したプレイスホルダーへの報告を行う実践的なコンテストになります。GH05TBUSTERS は調査や対策が困難である状況において、プレイスホルダーへの報告書が理解し易く丁寧であったことが AWS 賞受賞の決め手でした。 GH05TBUSTERS の皆様から情報危機管理コンテストへの参加の経緯や意義について、お話をお聞きすることが出来ましたので、インタビュー記事を通してそこで得た学び、これからの IT 、クラウドや AWS への期待をうかがいできればと思います。 (写真左から) GH05TBUSTERS 名古屋工業大学 齋藤掛井研究室 情報工学科 4 年 東 政澄 氏 情報工学科 4 年 斎藤 勇斗 氏 情報工学科 4 年 佐藤 優樹 氏 情報工学科 4 年 佐々木 康太 氏 コンテストに参加したきっかけ AWS : 今回の危機管理コンテストに参加するきっかけをお聞かせいただけますか。 佐々木 : 研究室の先輩が年々通過していて、去年( 2023 年)の 12 月ごろに先輩から来年はぜひ参加しようと言われました。ちょうど人数が一杯だったので、未経験のチームを作ろうということになりました。 AWS : 未経験のチームとのことで、本選の準備を進める上でどのような苦労がありましたか？ 佐々木 : 一次予選は先輩のアドバイスもなく、過去問を見て対策するくらいでした。通るかなと思いながらビクビクしていました。でも、自分たちの力だけで一次予選を通過することが出来ました。本戦で実際に攻撃を受けて対処するのは初めての経験でした。練習した時は、攻撃が分かっても、そこからどうすればいいのか分からず探り状態でした。そこに慣れていくのが大変でした。 AWS : 練習について教えてください。 佐々木 : 過去に大会に出た先輩たちが本番に似た環境を独自で作ってくれていました。そこで先輩が用意した攻撃スクリプトを受けて、それに対応するような練習をしました。 AWS : 決勝戦での分担はどのように決められたのでしょうか？ 佐々木 : サークルで渉外対応をしていたので、ある程度慣れていたから電話担当になりました。 東 : トラブルチケットを最後に提出するので、聞きながら書く人がいないと難しいと思い、書記を担当をしました。 佐藤 : その他のメンバーがログの監視と分析を担当することにしました。 AWS : 電話対応や書記が選任なのは大切だからということでしょうか？ 佐々木 : 先輩からログ監視と電話対応を二人でやるのが効率的と言われたので、得意な人がそちらを担当しました。未経験なので、レベル差はあまりありませんでした。 本戦で工夫したところ 佐藤: ユニフォームのTシャツを作りました(一同 笑) 東 : Discord で画面共有をしながら進めました。全員が同じ画面を見られるようにしていました。ただ、解像度が良くなかったので、事前に打ち合わせをしておけば良かったです。でも、大体の概要は把握できたので、指示を出し合えました。 AWS : 指示は誰が出していましたか？ 佐々木: 私がリーダーにはなっていましたが、リーダーが判断して回すよりは、4 人で各自のアイデアを話し合って決めていく感じでした。誰か一人が動かすのではなく、チームで動いていました。 AWS : プレイスホルダーへの報告書が AWS 賞の決め手でしたが、報告書で工夫したことはありますか？ 佐々木 : 時間が短かったので、みんな急かされている状態だったと思います。そういう中で、できるだけ分かりやすく伝えようと心がけました。みんなも同じようにわかり易くしたので、それが反映されたのだと思います。一旦冷静に構えるのも大切だと感じました。 東: レポートを報告する際も、難しい単語は事前に説明を入れるなど、大学一年生くらいに分かりやすいように心がけました。 AWS : サポート役の AWS の社員とのやり取りでは、コミュニケーションで何を気をつけましたか？ 斎藤 : 現在どういう状況に困っているのかを簡潔に分かりやすく伝え、アドバイスをもらって、早く戻って実行することを意識しました。 東 : 「AWS のサポートの方だから分かるだろう」ではなく、AWS を知らない人でも分かるように伝えました。 後輩や今後参加される方に対して 佐々木: 授業で習っただけでは、攻撃が来た時にどういうものが映るのか経験する機会がありません。本番に行けなくても練習だけでも良い経験になると思います。一次予選の内容もコンサルっぽい業務で、リスクマネジメントの面でセキュリティの分野に行かなくても良い経験になると思うので、色んな人に参加してほしいです。 東 : 同感です。 AWSやクラウドに感じる可能性 AWS : 事前ワークショップ 以前にクラウドについては触ったことがありましたか？ 東 : 実験の一環で一度だけ触った程度でした。 佐々木, 斎藤, 佐藤 : 触ったことは無かったです。 AWS : 事前ワークショップの内容はどうでしたか？ 佐々木 : クラウドを使うと言われても、別の企業が持っているサーバーを使うくらいの認識しかありませんでした。実際にどういう操作をすればできるのかを体験できて面白かったです。 AWS : クラウドの触った後でイメージに変化はありましたか？ 斎藤 : コンテストが終わった後に EC2 を使ってウェブアプリケーションを公開したいと頼まれ、ワークショップの資料を見ながら RDS などを構築しました。 斎藤 : サービスがこんなにたくさんあると思っていませんでした。公開するのは簡単だと思っていましたが、セキュリティを強化するためには、複数のサービスを組み合わせる必要があり、拡張性が高いと感じました。 AWS : 逆にクラウドのイメージで変わらなかったところは何でしたか？ 東 : サーバーの動作自体は変わっていないと感じました。オンプレミスの環境とクラウドの環境で大差なく動くのは便利だと思いました。 将来のキャリアイメージ AWS : 将来のキャリアイメージについてお聞きしたいと思います。皆さんはどのようなキャリアを考えていますか？ 佐々木 : まずは大学院に行って、今の研究を発展させてセキュリティ分野の知識をつけたいです。その後は、コンサル系の仕事でお客様と話ができるような仕事に就きたいです。コンテストでお客様対応が楽しかったので、そういう仕事がしたいです。 斎藤 : 私もインシデント対応やお客様と話しながらセキュリティを強化する仕事ができたらと思っています。 東 : 私は作る側に回りたいと思っています。サービスを作っていく人間になりたいです。 佐藤 : セキュリティ系がカッコいいので、職種は限らずセキュリティ関係の職業に就きたいです。 AWS : 皆さんにとってセキュリティを学ぶことにはどのような価値がありますか？ 東 : セキュリティは範囲が広いので総合格闘技の様です。幅広く学んでいく必要があると思います。様々な知識を身につけて、それを開発に活かしていけたらと考えています。 佐々木 : サークルで使う Web アプリを作っています。公開範囲を設定する際の要望と影響範囲をコントロールするために、説得するための知識をつけたいです。 おわりに チーム GH05TBUSTERS の方々、お忙しい中インタビューに快く対応いただいてありがとうございました。 このブログは、2024 年 10 月 25 日時点の情報に基づいてソリューションアーキテクト 押川、深井 が執筆しました。

この記事は Serverless containers at AWS re:Invent 2024 (記事公開日: 2024 年 11 月 1 日) を翻訳したものです。 AWS re:Invent は、AWS が主催するグローバルなクラウドコンピューティングコミュニティ向けの大規模な学習カンファレンスです。今年は、 Amazon Elastic Container Service (Amazon ECS) チームと AWS Fargate チームが、生産性の向上、コストの最適化、ビジネスの俊敏性向上に役立つ最新のトレンド、イノベーション、ベストプラクティス、ヒントを共有します。2024 年 12 月 2 日から 12 月 6 日の期間、是非ラスベガスにてご参加ください。 Expo Hall の AWS サーバーレス kiosk または AWS モダンアプリケーションとオープンソースゾーンにアクセスして、AWS でのモダンアプリケーションの構築について専門家に質問したり、デモンストレーションを見たり、オープンソースチームと交流したりできます。ぜひお立ち寄りください！ 参加いただけるセッション Amazon ECS と AWS Fargate のセッションは、今年は SVS – サーバーレスコンピュート&コンテナトラックの一部として実施されます。「“Celebrating 10 years of pioneering serverless and containers” (サーバーレスとコンテナのパイオニアとしての 10 周年を祝う)」 ( SVS211 ) や「 “Compute innovation for any application, anywhere” (あらゆるアプリケーションのためのコンピューティングイノベーション)」( CMP215 ) などのリーダーシップセッションにも是非ご参加ください。今年のトラックのハイライトには、Fannie Mae のサーバーレスコンテナジャーニーを特集した「“Unleashing the power of Amazon ECS for platform teams”(プラットフォームチームのための Amazon ECS の力を解き放つ)」（ SVS330 ）、「 “Navigating the cloud compute landscape with Amazon ECS” (Amazon ECS におけるクラウドコンピューティングの世界を探る)」（ SVS327 ）、「“Simplifying multi-tenancy with SaaS applications on AWS Fargate” (AWS Fargate でのSaaSアプリケーションによるマルチテナンシーの簡素化)」（ SVS329 ）などがあります。セッション ID をクリックして予約してください。 これまでと同様に、カンファレンスではさまざまなセッション形式が提供されています。 ブレイクアウトセッション: AWS エキスパート、ビルダー、お客様による講義形式のプレゼンテーション チョークトーク: さまざまなトピックに関する専門家によるインタラクティブなセッション。自分の経験やフィードバックを共有するセッション ワークショップ: 新しいテクノロジーの探求に役立つハンズオン形式の学習セッション。ご自身のラップトップ PC をご持参ください ビルダーセッション: AWS エキスパートが行う小規模なセッションで、自分のラップトップ PC で何らかのプロジェクトを構築します ライトニングトーク: Expo Hall で開催されるこの 20 分間のプレゼンテーションです。特定の顧客事例、サービスデモ、AWS パートナーサービスなどに特化しています プラットフォームチーム向けの Amazon ECS コア機能 SVS327 | Navigating the cloud compute landscape with Amazon ECS (Amazon ECS におけるクラウドコンピューティングの世界を探る) (ブレイクアウト) SVS329 | Simplifying multi-tenancy with SaaS applications on AWS Fargate(AWS Fargate 上の SaaS アプリケーションによるマルチテナンシーの簡素化) (ブレイクアウト) SVS330 | Unleashing the power of Amazon ECS for platform teams (プラットフォームチーム向けの Amazon ECS の力を解き放つ) (ブレイクアウト) コスト最適化とレジリエンシー SVS334 | Optimizing workloads for speed & cost using Amazon ECS and AWS Fargate (Amazon ECS と AWS Fargate を使用してワークロードをスピードとコストに合わせて最適化する) (チョークトーク) SVS409 | Deep dive into Amazon ECS resilience and availability (Amazon ECS のレジリエンスと可用性を深く掘り下げる) (ブレイクアウト) オブザーバビリティ SVS328 | Enhancing observability in Amazon ECS to gain actionable insights (Amazon ECS のオブザーバビリティを強化して実用的な洞察を得る) (ブレイクアウト) SVS413 | Unveiling Amazon ECS workloads with managed open source observability (マネージド型オープンソースオブザーバビリティによる Amazon ECS ワークロードの紹介) (チョークトーク) セキュリティとネットワーク SVS301 | Architecting for data protection and compliance with Amazon ECS (Amazon ECS のデータ保護とコンプライアンスのためのアーキテクチャ) (ビルダーセッション) SVS309 | Securing application networking with Amazon ECS Service Connect (Amazon ECS サービスコネクトによるアプリケーションネットワークの保護) (ワークショップ) SVS341 | Achieving a secure microservices architecture on Amazon ECS (Amazon ECS での安全なマイクロサービスアーキテクチャの実現) (ブレイクアウト) SVS342 | Securing Amazon ECS workloads with AWS Signer and Amazon GuardDuty (AWS Signer と Amazon GuardDuty による Amazon ECS ワークロードの保護) (ブレイクアウト) アプリケーション開発のための Amazon ECS モダナイゼーション SVS310 | Learn multi-tier application architectures on Amazon ECS (Amazon ECS の多層アプリケーションアーキテクチャを学ぶ) (ワークショップ) SVS302 | Migrate and modernize your containerized workloads with AWS Fargate (AWS Fargate を使用してコンテナ化されたワークロードを移行およびモダナイズする) (チョークトーク) SVS332 | Build secure & performant apps easily with Amazon ECS & AWS Fargate (Amazon ECS と AWS Fargate を使用して、安全でパフォーマンスの高いアプリを容易に構築) (チョークトーク) スケーリングとパフォーマンス SVS335 | Scaling to 1000s of containers in minutes with Amazon ECS (Amazon ECS を使用して数分で数千のコンテナにスケーリング) (チョークトーク) SVS402 | Lazy loading container images with Seekable OCI (SOCI) (Seekable OCI (SOCI) によるコンテナイメージの遅延読み込み) (ワークショップ) SVS414 | Building resilient Amazon ECS applications with chaos engineering (カオスエンジニアリングによる回復力のある Amazon ECS アプリケーションの構築) (チョークトーク) デプロイメント SVS308 | Demystifying Amazon ECS deployments for secure and automated releases (安全で自動化されたリリースのための Amazon ECS デプロイの謎を解き明かす) (ワークショップ) SVS338 | Continuous deployment on Amazon ECS (Amazon ECS での継続的デプロイ) (ライトニングトーク) SVS340 | Deployment best practices for reliable rollouts using Amazon ECS (Amazon ECS を使用して信頼性の高いロールアウトを行うためのデプロイのベストプラクティス) (ブレイクアウト) イベント駆動型アーキテクチャとデータ処理 SVS333 | Common patterns for storing data for Amazon ECS workloads (Amazon ECS ワークロードのデータを保存するための一般的なパターン) (チョークトーク) SVS336 | Serverless data ingestion and processing using containers on Amazon ECS (Amazon ECS 上のコンテナを使用したサーバーレスデータの取り込みと処理) (チョークトーク) SVS339 | Building event-driven architectures using Amazon ECS with AWS Fargate (AWS Fargate で Amazon ECS を使用してイベント駆動型アーキテクチャを構築する) (ブレイクアウト) 生成 AI SVS304 | Extend generative AI capabilities with serverless containers and RAG (サーバーレスコンテナと RAG による生成 AI機能の拡張) (ビルダーセッション) SVS331 | Supercharge your AI and ML workloads on Amazon ECS (Amazon ECS で AI と ML のワークロードを強化する) (ブレイクアウト) 現地で参加できない場合でも、基調講演とリーダーシップセッションのライブ配信に参加できます。イベントに登録して、バーチャル専用パスを選択してください。ブレイクアウトセッションは、re:Invent 終了後に AWS イベントの YouTube チャンネル でご覧いただけるようになります。 これらのセッションについて詳しく知りたい場合、または弊社の専門家とのミーティングを手配したい場合は、AWS アカウントチームにお問い合わせください。また、イベント中に Expo Hall を訪れて、AWS のスペシャリストと直接お話いただくこともできます。 re:Invent 2024 でお会いできるのを楽しみにしています！その他の学習リソースについては、 Amazon ECS にアクセスして開始してください。 翻訳はパートナーソリューションアーキテクトの高橋達矢が担当しました。原文は こちら です。

11 月 18 日週は、AWS からなんと 197 もの新サービスがリリース されました。つまり、 AWS re:Invent 2024 に近づきつつあるということです。 AWS のニュースブログチームでも、皆さんに楽しく読んでいただけるように、サービスチームによる素晴らしいリリースを紹介する re:Invent 関連の新しいブログ記事の仕上げに取りかかっています。 最も興味深いニュースは、 AWS Trainium チップ 開発の 主要なトレーニングパートナーとして、Anthropic との戦略的コラボレーションを拡大していることです。これに加えて、AWS は Anthropic の Claude モデルを Amazon Bedrock でデプロイするための主要なクラウドプロバイダーでもあります。 私たちは、このようなコラボレーションを通じて、 生成 AI テクノロジーでお客様が達成できることの限界を押し広げていきます。 11 月 18 日週のリリース AWS バンドル機能のリリースをいくつかご紹介します。 Amazon Aurora – Amazon Aurora Serverless v2 では、 0 Aurora キャパシティユニット (ACU) へのスケーリング がサポートされるようになりました。0 ACU なら、データベースが非アクティブ状態の間にコストを抑えることができます。データベースは ACU を 0.5 個ではなく、0 個までスケールダウンできるようになりました。Amazon Aurora が Amazon RDS データベースプレビュー環境の MySQL 8.0.39 および PostgreSQL 17.0 と互換性を持つようになりました。 Amazon Bedrock – Amazon Bedrock Flows (以前は Prompt Flows と呼ばれていました) の一般提供により、コードを記述しなくても、複雑な生成 AI ワークフローをすばやく構築して実行できるようになりました。Amazon Bedrock ナレッジベースでは、検索拡張生成 (RAG) アプリケーションを構築するための バイナリベクトル埋め込み がサポートされるようになりました。また、Amazon Bedrock では、基盤モデル (FM) からより高い品質の応答が得られるようにプロンプトを書き換えるための プロンプト最適化 のプレビュー版も公開されました。 AWS Amplify AI キット を使用すると、データを簡単に活用して Bedrock AI モデルからカスタマイズされた応答を取得し、チャット、会話検索、要約などの AI 機能を備えたウェブアプリを構築できます。 Amazon CloudFront – クライアントとサーバー間で HTTP/2 接続を介した双方向通信を可能にする gRPC アプリケーションを Amazon CloudFront で 使用できます。Amazon CloudFront では、VPC プライベートサブネットでホストされているアプリケーションからコンテンツを配信するための 仮想プライベートクラウド (VPC) オリジン と、世界中のすべての CloudFront エッジロケーションに接続するための専用の IP アドレスリストを提供する エニーキャスト静的 IP が導入されました。また、CloudFront Functions 内で オリジンを変更 することで、リクエストごとにオリジンサーバーを条件付きで変更または更新したり、 新しいログ設定や配信オプション を使用したりすることもできます。 Amazon CloudWatch – フィールドインデックス と ログ変換 を使用して、CloudWatch ログのログ分析を大規模に改善できます。また、CloudWatch Application Signals による 強化された検索および分析エクスペリエンス と ランタイムメトリクスのサポート を使用したり、CloudWatch Real User Monitoring (RUM) のウェブバイタルアノマリーから直接 パーセンタイル集計とシンプルなイベントベースのトラブルシューティング を使用したりすることもできます。 Amazon Cognito – パスキー、E メール、テキストメッセージを使用したサインインなど、 パスワードなしの認証 によって、アプリケーションへのユーザーアクセスを保護できます。Amazon Cognito では、お客様が会社やアプリケーションのブランディングに合わせてパーソナライズできるホスト型サインインおよびサインアップエクスペリエンス、 マネージドログイン が導入されました。Cognito は、ユーザープールの新しい機能階層である Essentials と Plus 、および開発者に焦点を当てた新しいコンソールエクスペリエンスをリリースします。詳細については、 Donnie のブログ記事 をお読みください。 Amazon Connect – 新しい 顧客プロファイルとアウトバウンドキャンペーン を使用すると、顧客のニーズが潜在的な問題となる前に積極的に対応できます。Amazon Connect Contact Lens は、 カスタムダッシュボードの作成 と、既存のダッシュボードからのウィジェットの追加または削除のサポートを開始しました。新しい Amazon Connect Email を使用して、顧客から会社のアドレスに送信された E メールや、ウェブサイトまたはモバイルアプリのウェブフォームから送信された E メールを受信して、返信することができます。 Amazon EC2 – Amazon Application Recovery Controller (ARC) の ゾーンシフトとゾーン自動シフト を使用して、Auto Scaling グループ (ASG) の EC2 インスタンスの起動を障害のあるアベイラビリティーゾーン (AZ) から遠ざけ、別の AZ で正常に動作していないアプリケーションをすばやく回復できます。Application Load Balancer (ALB) は、 HTTP リクエストとレスポンスヘッダーの変更 のサポートを開始しました。これにより、アプリケーションコードを変更しなくても、アプリケーションのトラフィックとセキュリティ状態をより細かく管理できるようになります。 AWS End User Messaging (別名 Amazon Pinpoint) – SMS および MMS チャネルを介して送信されたメッセージの フィードバックを追跡 したり、国のルール設定を上書きして個々の電話番号への メッセージを明示的にブロックまたは許可 したり、 SMS リソースのコスト配分タグ を使用してリソースに関連する各タグの支出を追跡したりできるようになりました。AWS End User Messaging は、Amazon EventBridge との統合もサポートするようになりました。 AWS Lambda – Lambda SnapStart for Python と .NET 関数 を使用すると、1 秒未満という高速の起動パフォーマンスを実現できます。AWS Lambda は、 非同期呼び出しの障害イベント送信先 として Amazon S3 をサポートするようになりました。また、Lambda を使用して構築されたサーバーレスアプリケーションのヘルスとパフォーマンスを簡単にモニタリングできる Amazon CloudWatch Application Signals のサポートも開始しました。Apache Kafka イベントソースをサブスクライブするイベントソースマッピング (ESM) で、新しい Node.js 22 ランタイム と プロビジョンドモード を使用することもできます。 Amazon OpenSearch Service – 1 つのクラスターを 1,000 個のデータノード (1,000 個のホットノードおよび/または 750 個のウォームノード) にスケールして、25 ペタバイトのデータを管理できます。Amazon OpenSearch Service では、OpenSearch の検索および分析機能を拡張するための新しいプラグイン管理オプション、 Custom Plugins が導入されました。 OpenSearch Serverless – OpenSearch SQL と OpenSearch Piped Processing Language (PPL) クエリ を使用して、既存の SQL スキルとツールを活用できます。 バイナリベクトルと FP16 圧縮 では、メモリ要件を下げてコストを削減できます。また、 ポイントインタイム (PIT) 検索 を使用して、OpenSearch Serverless の特定の瞬間に固定されたデータセットに対して複数のクエリを実行できます。 OpenSearch Ingestion – AWS Lambda を使用して OpenSearch Ingestion パイプラインでカスタム Lambda 関数を定義できるようになりました。また、 Amazon Security Lake へのセキュリティデータの書き込み のサポートが開始され、一般的なサードパーティーソースからセキュリティデータを取り込んで変換できるようになりました。 Amazon Q Business – 表形式検索 を使用して、Q Business に取り込んだドキュメントに埋め込まれたテーブルから、回答を抽出できます。再度アップロードするのではなく、 ファイルをドラッグアンドドロップ でアップロードして、最近アップロードしたファイルを新しい会話で再利用できます。Amazon Q Business では、 Smartsheet 全般、 Asana 、 Google カレンダー との統合 (プレビュー版) がサポートされるようになりました。これにより、選択したデータソースとインデックスを自動的に同期できます。Google Chrome、Mozilla Firefox、Microsoft Edge 用の Q Business ブラウザ拡張機能 を使用することもできます。 Amazon Q Developer – 表示している AWS マネジメントコンソールのページ に関連する質問を直接行うことができるため、クエリでサービスやリソースを指定する必要はありません。また、IDE で Q Developer が生成した カスタマイズ可能なチャット応答 を使用して、Q Developer をプライベートコードベースに安全に接続し、より正確なチャット応答を受信することもできます。最後に、AWS コンソールモバイルアプリの 音声入力および出力機能 を会話プロンプトと併用して、AWS アカウントのリソースを一覧表示できます。 Amazon QuickSight – Layer Map を使用して販売地域やユーザー定義リージョンなどのカスタムの地理的境界を視覚化し、 Image Component で画像を直接アップロードして、会社のロゴの追加などのさまざまな用途に使用できます。Amazon QuickSight は、既存のダッシュボードまたは分析から現在の分析に ビジュアルをインポート する機能と、プレビュー版の Highcharts Core ライブラリを使用して、カスタムのビジュアライゼーションを作成する Highcharts ビジュアル を提供します。 Amazon Redshift – Amazon EC2 インスタンス上の Confluent Managed Cloud およびセルフマネージド Apache Kafka クラスターの より幅広いストリーミングソース からデータを取り込むことができます。また、 強化されたセキュリティデフォルト からデータを取り込むこと可能です。これにより、データセキュリティのベストプラクティスを順守し、潜在的な設定ミスのリスクを軽減できます。 AWS System Manager – 新たに改善された AWS Systems Manager を使用すると、ノードを大規模に管理するために要望の多かったクロスアカウントおよびクロスリージョンのエクスペリエンスが実現します。AWS Systems Manager は、 Windows Server 2025、Ubuntu Server 24.04、Ubuntu Server 24.10 を実行するインスタンスのサポートを開始しました。 Amazon S3 – ユーザーに代わってオブジェクトを期限切れにするよう S3 Express One を設定し、S3 Express One Zone で データをオブジェクトに追加 することができます。 Mountpoint for Amazon S3 では、Amazon S3 Express One Zone を高パフォーマンスのリードキャッシュとして使用することもできます。Amazon S3 Connector for PyTorch は 分散チェックポイント (DCP) のサポートを開始し、Amazon S3 にチェックポイントを書き込む時間が短縮されました。 Amazon VPC – ネットワーク管理者およびセキュリティ管理者が VPC のインターネットトラフィックを正式にブロックできるようにする新しい一元化された宣言型コントロール、 Block Public Access (BPA) for VPC を使用できます。Amazon VPC Lattice では Amazon ECS とのネイティブ統合 の提供が開始され、コンテナ化されたアプリケーションを簡単にデプロイ、管理、スケールできるようになりました。 このブログで取り上げなかったリリースニュースはまだまだあります。詳細については、「 AWS の最新情報 」を参照してください。 AWS re:Invent でバーチャルにお会いしましょう 12 月 2 日週、私たちは米国ラスベガスで AWS の最新情報を聞き、エキスパートから学び、グローバルクラウドコミュニティとつながります。re:Invent に参加する場合は、出発前に アジェンダ 、 セッションカタログ 、 参加者ガイド を確認してください。 2024年の re:Invent に直接参加できない方のために、AWS では 基調講演とイノベーショントークをライブストリーミング するオプションもご用意しています。 オンラインパスに登録 することで、イベント後にオンデマンドの基調講演、イノベーショントーク、および厳選されたブレイクアウトセッションにアクセスできます。また、ワンクリックでイベント登録が可能で、多くの AWS ツールやサービスにアクセスできる個人アカウント、 AWS ビルダー ID にもご登録いただけます。 12 月 2 日週もどうぞお楽しみに! – Channy 原文は こちら です。

11 月 22 日、新たに改善された AWS Systems Manager をご紹介します。これにより、ノードを大規模に管理するために要望の多かったクロスアカウントおよびクロスリージョンのエクスペリエンスが実現します。 新しい System Manager エクスペリエンスでは、 Amazon Elastic Compute Cloud (EC2) インスタンス、コンテナ、他のクラウドプロバイダーの仮想マシン、オンプレミスサーバー、エッジの モノのインターネット (IoT) デバイスなど、さまざまなインフラストラクチャタイプを含むすべてのマネージドノードを一元的に可視化できます。 Systems Manager Agent (SSM Agent) がインストールされていて、Systems Manager に接続されている場合、これらは「マネージドノード」と呼ばれます。 SSM Agent が何らかの理由でノードでの動作を停止すると、Systems Manager はノードとの接続を失い、そのノードは「非マネージドノード」と呼ばれます。 新しいアップデートでは、Systems Manager を使用して非マネージドノードを簡単に検出し、トラブルシューティングすることもできます。自動診断を実行したり、スケジュールを設定したりすることも可能です。自動診断では推奨ランブックが提供され、このランブックを実行して問題を解決し、接続を再確立して再びマネージドノードにすることができます。 また、Systems Manager は Amazon Q Developer とも統合されました。Amazon Q Developer は、最も高機能な生成 AI 搭載のソフトウェア開発アシスタントです。マネージドノードに関する質問を自然言語で Amazon Q Developer に尋ねると、迅速なインサイトが得られるだけでなく、Systems Manager へのリンクが直接表示され、アクションを実行したり、さらに詳しく調べたりできます。 このリリースでは、 AWS Organizations を使用することも可能です。Systems Manager との新しい統合により、委任された管理者が組織全体のノードを一元管理できるようになりました。 これらの新機能のいくつかを実証するのに役立つ簡単な例を見てみましょう。 あなたはクラウドプラットフォームエンジニアで、組織内の Windows Server 2016 Datacenter を実行しているすべてのノードを交換することを目的とした移行計画を主導しているとします。新しい Systems Manager エクスペリエンスを使用して、計画に含める必要があるすべてのノードに関する情報をすばやく収集しましょう。 ステップ 1 – Amazon Q Developer への質問 最も簡単な出発点は、Amazon Q Developer を使用して、見つけたいものについて自然言語で尋ねることです。AWS コンソールを使用して Amazon Q チャットボットを開き、 Find all of my managed nodes running Microsoft Windows Server 2016 Datacenter in my organization と入力します。 Amazon Q はすぐに回答を返します。条件を満たすノードが 10 個あることが示され、各ノードの概要を記載したリストが表示されます。 System Manager の新しい ノードの探索 ページにリダイレクトするリンクもあり、このページで詳細を確認できます。リンクをクリックしてみましょう。 ステップ 2 – インフラストラクチャの見直し ノードの探索 ページには、組織のすべてのマネージドノードの包括的な概要が表示されます。また、結果をグループ化したりフィルタリングしたりして、すばやくアクセスできるようにするオプションが用意されています。この場合、結果は既に オペレーティングシステム名 でフィルタリングされており、 Microsoft Windows Server 2016 Datacenter を実行しているすべてのノードのリストが提供されていることがわかります。 これは素晴らしい起点となります! レポートをダウンロードしてノードを移行計画に追加し、作業を終了することもできます。ただし、このページにはマネージドノードに関する情報のみが表示されます。プランに含める必要のある非マネージドノードは存在するのでしょうか? 調べてみましょう。 ステップ 3 – 非マネージドノードの処理 メニューを開き、 ノードインサイトのレビュー ページに移動します。ここには、インサイトに富んだインタラクティブなグラフを提供するウィジェットを含むダッシュボードが表示されます。これを使用して、ノードに関する詳細情報を調べたり、アクションを実行したりできます。例えば、 マネージドノードタイプ の円グラフにはマネージドノードのタイプが表示され、 SSM Agent バージョン のグラフには、そのノードで実行されている SSM Agent のさまざまなバージョンの概要が表示されます。ウィジェットを追加したり置き換えたりして、このビューをカスタマイズすることもできます。 非マネージドノードを調査して、移行計画に追加する必要のあるノードを見逃さないようにしたいと考えています。 ノード概要 ウィジェットには、非マネージドノードが 2 つあることが明確に表示されています。これは、これらのノードに SSM Agent がインストールされていない可能性があることを示しています。その場合、手動で調査する必要があります。ただし、SSM Agent の権限またはネットワーク接続に問題があるために、Systems Manager がこれらのノードを管理したり、他のマネージドノードと同様に扱ったりできない場合もあります。新しい Systems Manager エクスペリエンスでは、SSM Agent の問題を簡単にトラブルシューティングして修正できるので、今すぐ試してみましょう。 まず、非マネージドノードが表示されているグラフの一部を選択します。これにより、ワンクリックですべての非マネージドノードの包括的な診断を開始するオプションが表示されます。これを実行してみましょう。 診断では、欠落している 仮想プライベートクラウド (VPC) エンドポイント、誤った VPC DNS 設定、SSM Agent による Systems Manager への接続を妨げている可能性のある誤ったインスタンスセキュリティグループの設定などの主要な設定を確認します。スキャンが完了すると、 誤設定された VPC エンドポイント の結果が 2 つ表示されていることがわかります。また、問題を解決するために実行できる推奨ランブックを含む、サイドパネルを開くためのリンクと、関連するドキュメントへのリンクも表示されます。 推奨ランブックの実行を選択すると、変更の詳細なプレビューが表示されます。これには、使用される入力パラメーターに加えて実行されるアクションの完全な概要、関連するステップの内訳を表示するリンク、この実行のターゲットノードが含まれます。 先に進んで [実行] を選択しましょう。これにはコストが発生する可能性があるので、実行する前に必ず確認してください。このページでは、各ノードの問題を解決するための手順を説明しているので、進捗状況を確認できます。 なるほど! 修復が完了すると、Systems Manager が 2 つのノードの SSM Agent の問題を検出して修正したことがわかります。つまり、Systems Manager はそれらのノードで実行されている SSM Agent に正常に接続して「マネージドノード」にすることができます。 これを確認するには、 ノードの探索 ページに戻って、「非マネージドノード」の数が 0 に減少していることを確認します。 これですべてのノードが管理されたので、移行計画に追加する必要があるすべてのノードのリストを作成する準備が整いました。 ステップ 4 – レポートのダウンロード ノードの検索 ページに戻ると、Microsoft Windows Server 2016 Datacenter を実行しているノードの数が 10 から 12 に増えていることがわかります。 つまり、自動診断で修正した以前は管理されていなかったノードが、実際にターゲットオペレーティングシステムを実行しているということです。 これはまさに必要としている情報なので、 レポート をダウンロードすることにします。ファイル名を指定してから、含める列など、いくつかのオプションを選択します。この場合、列名を含む行を使用した CSV ファイルをダウンロードすることにします。 これで完了です。 インフラストラクチャ全体でアップグレードが必要なノードに関する詳細情報が記載された CSV を入手できました。そして何より素晴らしいのは、 移行を進める準備ができたら、Systems Manager を使用してアップグレードを自動化することもできるということです。 まとめ Systems Manager は、コンピューティングインフラストラクチャを可視化して制御し、運用アクションを大規模に実行するための重要なツールです。新しいエクスペリエンスでは、AWS アカウント、オンプレミス、マルチクラウド環境のすべてのノードを、一元化されたダッシュボードを通じて一元的にクロスアカウント、クロスリージョンで表示できるようになりました。また、Amazon Q Developer との統合による自然言語クエリ、ワンクリックでの SSM Agent のトラブルシューティングも可能です。Systems Manager コンソールに移動し、わかりやすい指示に沿って操作することで、追加費用なしで新しいエクスペリエンスを有効にできます。 新しい Systems Manager エクスペリエンスの詳細については、 ドキュメント をご覧ください。 このエクスペリエンスの完全なビジュアルツアー については、このインタラクティブデモをご確認ください。 原文は こちら です。

Gartner は、2 つ目の Magic Quadrant for Distributed Hybrid Infrastructure (DHI) を公開しました。このレポートでは、 Amazon Web Services (AWS) が再びリーダーとして選出されています。AWS には、この DHI ポートフォリオにおいて、 AWS Outposts 、 AWS Snowball 、および AWS Local Zones という 3 つの製品を有しています。付随する Gartner の Critical Capabilities for DHI では、AWS は、ハイブリッドインフラストラクチャ管理、エッジコンピューティング、保証されたワークロード、人工知能と機械学習 (AI/ML) など、Gartner が評価した 6 つのユースケースのうち 4 つで 1 位にランキングされ、コンテナ管理のユースケースでは上位 2 社のうちの 1 社にランキングされています。 Gartner は、ベンダーが製品やサービスを効果的に提供する能力を測定する実行能力と、ベンダーの市場理解と将来の成長戦略を評価するビジョンの完全性に基づいて、10 社の DHI プロバイダーを評価しています。 2024 年の Gartner Magic Quadrant for DHI のグラフを次に示します。 Gartner は、AWS の強みを次のように認識しています: 主要なパブリッククラウドプロバイダー – AWS DHI ソリューションは、インフラストラクチャをデータセンターとエッジロケーションに拡張し、残りのプライベートクラウドインフラストラクチャからの移行も希望する AWS パブリッククラウドのお客様にとって魅力的です。 as a Service 配信 – AWS Outposts のフルマネージドインフラストラクチャの配信により、運用が簡素化され、いくつかのオンプレミスのテクノロジーとの統合を含む、インフラストラクチャ管理に対する手間のかからない単一ベンダーアプローチが可能になります。 AWS サポート – Gartner のクライアントは、AWS のワールドワイドサポートおよびサービスチームにとても満足していると報告しています。 このようにリーダーとして選出されたことは、低レイテンシー、ローカルデータ処理、データレジデンシー、またはオンプレミスの相互依存関係を伴う移行を必要とするワークロードのための、クラウドのエッジにおける当社のイノベーションを反映していると考えています。AWS では、真に一貫したクラウドエクスペリエンスを実現するために、必要とする場所がどこであっても、同じ AWS インフラストラクチャ、AWS サービス、API、ツールを提供します。 ワークロードが、 AWS リージョン 、メトロエリア (AWS Local Zones を使用)、オンプレミス (AWS Outposts を使用)、通信ネットワーク ( AWS Wavelength を使用)、またはエッジ (AWS Snow Family を使用) のいずれで実行されているかにかかわらず、すべてのアプリケーションのために同じクラウド運用モデルを標準化できます。継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインの共通セットを標準化することで、デベロッパーのワークフローを合理化できます。また、IT インフラストラクチャの管理に必要な時間、リソース、運用リスク、メンテナンスのダウンタイムも削減されます。 加速されたイノベーションの例を挙げると、ML ワークロードのサポートを改善するために 最新世代の GPU 対応インスタンスを Local Zones に追加し、ロケーションの数を拡大しました。Outposts をより多くの国で利用できるようにし、Outposts でサポートされる AWS サービス ( AWS Elastic Disaster Recovery や Amazon Route 53 Resolver など) を追加して、 より容易な移行 と ディザスタリカバリ を実現し、アプリケーションの可用性を高め、パフォーマンスを改善しました。 さらに、Kubernetes コントロールプレーンとノードの両方をローカルで実行できるようにすることで、Outposts でのコンテナベースのワークロードの切断耐性を高め、マルチラック Outposts デプロイのために機能を強化しました。 詳細については、完全な 2024 年の Gartner Magic Quadrant for DHI レポート にアクセスしてください。 – Channy 原文は こちら です。 Gartner は、その調査出版物に記載されているベンダー、製品、またはサービスを推薦するものではなく、最高評価または他の認定を受けたベンダーのみを選定するようテクノロジーユーザーに助言するものでもありません。Gartner の調査出版物は、Gartner の調査組織による見解で書かれたものであり、事実を表明するものではありません。Gartner は、本調査に関して、明示または黙示を問わず、商品性または特定目的適合性に関する保証を含め、一切の保証を放棄します。 GARTNER は Gartner の登録商標およびサービスマークであり、Magic Quadrant は Gartner, Inc. および/またはその米国および他国の関連会社の登録商標であり、許可を得て使用されています。All rights reserved.

本稿は、2024 年 11 月 18 日に IBM &amp; Red Hat on AWS Blog で公開された “ Live Migration of Virtual Machines (VMs) with OpenShift Virtualization on ROSA and Amazon FSx for NetApp ONTAP ” を翻訳したものです。 私たちは、既存のパラダイムに挑戦する革新的なテクノロジーに度々直面します。アップストリームの KubeVirt プロジェクトをベースに構築された OpenShift Virtualization は、まさにそのような技術の一つです。 OpenShift Virtualization により、組織は従来の仮想マシン (VM) とコンテナ化されたアプリケーションを統一されたプラットフォーム上で同時に実行できます。これは特に、完全な刷新なしでモダナイゼーションを必要とするレガシーアプリケーションを持つ企業にとって価値があります。Kubernetes をコントロールプレーンとして使用することで、スケーラビリティ、自己修復、一貫した管理といった大きな利点が得られます。すでに OpenShift に投資している組織にとって、この統合は既存のツールとワークフローを活用できるため、運用が簡素化されます。これはまた、クラウドを活用してワークロードを Amazon Web Service (AWS) に移行し、その後クラウド上でビジネスをさらにモダナイズするお客様にとっても魅力的です。OpenShift Virtualization は VM を AWS に移行し、OpenShift と AWS のネイティブサービスを使用して進化させるためのリフト＆シフトアプローチを提供します。 OpenShift Virtualization は、追加のライセンスやサブスクリション費用なしで OpenShift に含まれています。AWS では、マネージドOpenShift である Red Hat OpenShift Service on AWS (ROSA) 上で実行でき、VM とコンテナ化されたアプリケーションを管理するためのオーケストレーション機能を活用できます。この統合により、チームは VM とコンテナの両方に対して同じ管理ツールとプラクティスを使用でき、運用の効率化と合理化が図れます。 コンテナオーケストレーターで VM を実行するアプローチは、アプリケーションを展開する際の柔軟性の増大するニーズに対応しています。組織は、別々のインフラストラクチャ環境を管理する必要なく、特定のワークロードの要件に基づいて VM とコンテナの両方を実行できます。 Amazon FSx for NetApp ONTAP は、ONTAP の一般的なデータアクセスと管理機能を備えた、AWS 上のフルマネージドの共有ストレージを提供します。FSx for ONTAP では、顧客アカウント内にストレージコンピュートノードまたは接続ストレージを追加する必要があります。ストレージのスケーリングと回復性は、顧客アカウントにエンドポイントのみが表示されるサービスチームアカウント内で実現されます。これにより、基盤となるインフラコストと、回復性を実現するための アベイラビリティゾーン （AZ）間のデータ転送コストが削減されます。FSx for ONTAP は、NetApp Trident をストレージオーケストレーターとして使用することで、OpenShift 上で実行されるアプリケーションや VM で利用できます。 ソリューションの概要 以下では、FSx for ONTAP を ROSA クラスターのデフォルト StorageClass として設定し、その後 FSx for ONTAP ストレージをボリュームとして利用するVMを作成する方法について見ていきます。また、ゲスト認証情報を使用して VM に接続する方法と、VM を現在のノードから新しいノードへライブマイグレーションを実行する方法についても説明します。 前提条件: AWS アカウント Red Hat アカウント ROSA クラスターの作成とアクセスのための 適切な権限 を持つ IAM ユーザー AWS CLI ROSA CLI OpenShift コマンドラインインターフェース (oc) Helm のインストール (ベアメタルのワーカーノードが 2 つ以上ある環境) ROSA クラスターにインストールされた OpenShift Virtualization 以下の図は、複数の AZ にデプロイされた ROSA Hosted Control Plane（HCP）クラスターを示しています。ROSA クラスターでは、コントロールプレーン（マスター）ノードはサービスチーム内にあります。一部のワーカーノードは OpenShift Virtualization をサポートするためにメタルインスタンスタイプとなっています。FSx for ONTAP ファイルシステムは同じ VPC 内にデプロイされています。NetApp Trident プロビジョナーは ROSA クラスターにインストールされており、この VPC のすべてのサブネットがファイルシステムに接続できるようになっています。OpenShift Virtualization は、OpenShift OperatorHub からオペレーターを使用してインストールされています。 ROSA と FSx for ONTAP のアーキテクチャ Trident CSI ドライバーのセットアップ デフォルトの StorageClass が trident-csi に設定されていることを確認してください。 次の yaml ファイルが StorageClass の作成に使用されました。 apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: trident-csi provisioner: csi.trident.netapp.io parameters: backendType: "ontap-nas" fsType: "ext4" allowVolumeExpansion: True reclaimPolicy: Retain 新しい OpenShift StorageClass StorageClassを作成する前に、以下の yaml ファイルがシークレットと ontap-nas ドライバーを使用したバックエンドオブジェクトの作成に使用されました。 apiVersion: v1 kind: Secret metadata: name: backend-fsx-ontap-nas-secret namespace: trident type: Opaque stringData: username: vsadmin password: apiVersion: trident.netapp.io/v1 kind: TridentBackendConfig metadata: name: backend-fsx-ontap-nas namespace: trident spec: version: 1 backendName: fsx-ontap storageDriverName: ontap-nas managementLIF: dataLIF: svm: credentials: name: backend-fsx-ontap-nas-secret デフォルトの VolumeSnapShotClasses が以下のように設定されていることを確認してください 以下の yaml ファイルが VolumeSnapshotClass の作成に使用されました kind: VolumeSnapshotClass metadata: name: fsx-snapclass driver: csi.trident.netapp.io deletionPolicy: Delete ボリュームスナップショットクラス デフォルト値が設定されていない場合、コンソールまたはコマンドラインから以下のように設定できます oc patch storageclass trident-csi -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}' oc patch VolumeSnapshotClasses fsx-snapclass -p '{"metadata": {"annotations": {"snapshot.storage.kubernetes.io/is-default-class": "true"}}}' OpenShift Virtualization でテンプレートから仮想マシンを作成する テンプレートから VM を作成するには Web コンソールを使用します。 ステップ 1: Red Hat OpenShift Virtualization コンソールから、VM を作成します。クラスター上で利用可能なテンプレートを使って VM を作成できます。 テンプレートから VM を作成 ステップ 2: VM のオペレーティングシステムを選択します。 この一覧から Fedora VM テンプレートを選択しています。 VM テンプレートの選択 ステップ 3: VM の詳細設定: VM に名前を付けた後、 Customize Virtual Machine をクリックします。 Disks タブを選択し、 Add disks をクリックします。ディスクの名前を変更し（分かりやすい意味のある名前を推奨）、StorageClass に trident-csi が選択されていることを確認します。 Save をクリックします。 Create VirtualMachine をクリックします。 VM の設定 ステップ 4: VM に接続されるストレージの定義: VM ストレージ ステップ 5: 前のステップで作成した StorageClass を使用して共有ストレージを追加します: FSx for ONTAP ストレージを VM に追加 数分後、VM は実行状態になります。 VM ステータス 接続されたストレージの確認: ストレージの確認を行います。まずディスクを確認し、次にファイルシステムを確認します。VM のファイルシステムには、パーティション、ファイルシステムの種類、マウントポイントが表示されます。 ディスク ファイルシステム VM 用に 2 つの PersistentVolumeClaim (PVC) が作成されます。1 つはブートディスク用、もう 1 つはホットプラグディスク用です。 PersistentVolumeClaim (PVC) PersistentVolumeClaim (PVC) の詳細を見ると、ボリュームは Trident-CSI ドライバによって提供されている事、そして shared または ReadWriteMany として設定されている事がわかります。 PersistentVolumeClaim (PVC) の詳細 VM の OS 内部から確認してみましょう。 ステップ 7: Web コンソールを開く ボタンをクリックして VM に接続し、 Guest の資格情報を使ってログインします。 VM コンソールを開く ステップ 8: 次に、使用されているディスク容量を確認し、ファイルシステム上にテストファイルを作成します。 df dd if=/dev/urandom of=random.dat bs=1M count=10240 df df コマンドの出力 仮想マシンのライブマイグレーション ライブマイグレーションとは、実行中の VM を、通常の運用を中断したり、ダウンタイムを発生させたり、エンドユーザーに悪影響を与えたりすることなく、あるホストから別のホストに移動するプロセスを指します。ライブマイグレーションは仮想化における重要な進歩と考えられています。実行中の OS、メモリ、ストレージ、ネットワーク接続を含む VM 全体を、現在のノードから移行先に移動することができます。 以下では、VM を現在のノードから新しいノードへライブマイグレーションする方法を見ていきます。FSx for ONTAP を介した共有ストレージのおかげで、VM が実行されている OpenShift ノードや AZ に関係なく、データにアクセスすることができます。 ステップ 9: 3 つのドットメニューの下にある Migrate をクリックします。 VM マイグレーション Overview タブから、マイグレーションが成功したことがわかります。 VM マイグレーション完了のステータス マイグレーション後のストレージの確認 再度、 VirtualMachines タブから VM に接続し、VM OS 内からストレージの状態を確認するコマンドを実行します。 df ls ストレージの確認 VM が新しいノードで実行されているにもかかわらず、ストレージ、ファイルシステム、およびボリュームクレームを確認すると、これらの項目はすべて変更されていないことがわかります。 結論: OpenShift Virtualization と FSx for ONTAP を組み合わせることで、ハイブリッド環境の最適化を目指す組織にとって強力なソリューションが実現します。OpenShift Virtualization により、ユーザーは統一された Kubernetes プラットフォーム内で VM とコンテナ化されたアプリケーションの両方を管理でき、運用効率と柔軟性が向上します。一方、FSx for ONTAP は、OpenShift とシームレスに統合される、スケーラブルで高性能なストレージを提供し、データへの容易なアクセスと保護を確保します。 この組み合わせにより、企業はレガシーワークロードを効率的に管理しながら、アプリケーションのモダナイゼーションを進めることができます。単一の環境で多様なワークロードを実行できることで、チームは運用を効率化し、複雑さを軽減し、リソースの利用効率を向上させることができます。OpenShift Virtualization と FSx for ONTAP は、今日のダイナミックな企業環境の要求に応える堅牢なインフラストラクチャを提供し、イノベーションと成長を可能にします。 Trident の詳細については、 NetApp Trident ドキュメント を参照してください。NetApp ソリューションドキュメントの Red Hat OpenShift Virtualization セクション で補足情報と ビデオ を確認できます。 <!-- '"` --> Ryan Niksch Ryan Niksch は、アプリケーションプラットフォーム、ハイブリッドアプリケーションソリューション、およびモダナイゼーションに焦点を当てたパートナーソリューションアーキテクトです。Ryanは人生で様々な役割を経験してきており、物事を改善することへの情熱と、自分が関わったものを見つけた時よりも少しでも良い状態で残したいという願いを持っています。 Banumathy Sundhar Banumathy Sundhar はテクニカルマーケティングエンジニアとしての現在の役割と、テクノロジーイネーブルメント専門家としての過去の役割において、プラットフォームと製品の普及促進、技術分野の深い探求、ライブまたは録画デモの提供、情報共有、ブログやライブ・バーチャルのセッションを通じた教育とスキルアップを行ってきました。ハイブリッドクラウド環境において、OpenShift クラスターと統合された NetApp 製品によるソリューションの技術的検証を顧客向けに提供してきました。前職では、ハンズオンラボを中心としたコンテンツ、技術プレゼンテーション、認定試験準備セッション、カンファレンスやインストラクターサミットでのラボセッションなど、技術トピックに関する幅広いトレーニングを開発・提供してきました。 Mayur Shetty Mayur Shetty は、Red Hat のグローバルパートナーおよびアライアンス組織のシニアソリューションアーキテクトです。業界での経験は約20年に及び、 4 年間在籍した Red Hat では、OpenStack Tiger チームのメンバーとしても活動してきました。それ以前は、Seagate Technology でシニアソリューションアーキテクトとして、OpenStack Swift、Ceph、その他のオブジェクトストレージソフトウェアを活用したソリューションを推進していました。また、IBM では ISV エンジニアリングをリードし、Oracle データベース、IBM システムおよびストレージに関するソリューションの開発に携わりました。Sun Cluster ソフトウェアの開発や、Sun Microsystems の ISV エンジニアリングチームでも活動してきました。 翻訳はパートナーソリューションアーキテクト 豊田が担当し、監修はネットアップ合同会社の藤原様に協力頂きました。原文は こちら です。

本ブログは、 味の素食品株式会社 と Amazon Web Services Japan が共同で執筆しました。 味の素食品株式会社は半世紀以上にわたり、安全・安心な製品を提供するクノール食品株式会社、味の素グループの包装を主軸とした高い技術力を持つ味の素パッケージング株式会社、「ほんだし®」や「Cook Do®」といった製品を生産する味の素株式会社の食品生産部門を一つにし、味の素グループ国内最大規模の生産会社として、2019 年 4 月 1 日に誕生しました。 同社では製品の写真から自動で賞味期限を読み取る機能を実装しました。これにより、工程管理における賞味期限印字の正誤確認 (指図通りの賞味期限を印字しているか) の作業品質の向上と作業負荷軽減を実現しています。この機能を実現するための Amazon Rekognition をはじめとしたサービスを活用した事例を紹介いたします。 &nbsp; 課題 「賞味期限」や「消費期限」は、国内製品においては食品表示基準第 3 条、業務用加工食品は食品表示基準第 10 条により表示を義務付けられており、誤った表示や表示なし製品が外部流通 (外部倉庫や小売店または店頭) に並ぶと法令達反となり、大規模なクレームや製品回収に繋がる加工食品業におけるもっとも重要な品質管理点のひとつです。 賞味期限印字の照合は印字検査装置による全数検査を実施していますが、そもそも印字する賞味期限が指図された正しい賞味期限と一致しているかどうかは人の目でしか確認ができていない状況でした。人間の認知エラー撲滅は困難であり、作業者の目視検査支援によるより一層の作業品質の向上が必要でした。 ソリューション 味の素食品株式会社では作業品質向上や標準化を目的とした包装業務用の電子帳票アプリケーションを開発しており、このアプリケーションとモバイル端末のカメラを用いた実装を検討しました。 製品に印字される賞味期限のフォントや文字列は製品 SKU や生産ラインごとに異なり、生産ライン上で高速に印字される賞味期限は文字の形状が多少変化することもあります。そのため、一般的な画像検査で用いられるパターンマッチング型の画像照合機能を、複数の工場間で標準化された電子帳票アプリケーションに構築しようとすると、画像照合アプリケーション側に数千もの字体を登録する必要があり運用が現実的ではありませんでした。 そこで、味の素食品株式会社では以下のように Amazon Rekognition の TextDetection を用いて、現場担当者が持つモバイル端末で撮影した写真から賞味期限を判別するアプローチを採用しました。本システムは以下構成で、インフラストラクチャの管理、運用負荷の少ないマネージドサービスで構成されています。 本機能の流れは以下です。 クライアントから Amazon CloudFront 経由で Amazon S3 上にある Web アプリケーションコンテンツを取得 製品の写真を撮り、画像をアップロード 画像は Amazon CloudFront 経由で Amazon S3 に保存されオブジェクトキーが確定 賞味期限識別の API をオブジェクトキーを引数に呼び出し AWS Lambda を起動 オブジェクトキーを引数に Amazon Rekognition を起動 Amazon S3 から画像を取得し文字識別 Amazon Rekognition の識別結果を処理して Amazon S3 に保存 賞味期限文字列をクライアントに返却 なお、上記「9. 賞味期限文字列をクライアントに返却」については Amazon Rekognition が画像から抽出する文字群から”賞味期限と想定される文字列”を抜き出す処理が必要となるため (賞味期限の表記方法は “YYYY/MM/DD”、”MM.DD.YYYY” などの表記方法が認められています) 正規表現によるマッチングを AWS Lambda 側で行い識別精度を高める工夫をしています。 また、読み取り精度に加えてレスポンスタイムの評価も技術検証中に実施しました。 工場のネットワーク帯域という制限がある中で、Amazon Rekognition の識別に要する時間、また AWS Lambda の起動に要する時間 (特にコールドスタートになるタイミング) によって作業性を悪化させてしまうという懸念がありました。この懸念に対しては、求める目標値をすり合わせし、確実な目標値達成を確認するために、AWS のソリューションアーキテクトからサンプルコードを提供し、検証をご支援しました。結果的に、レスポンスタイムについても不満無く、導入していただくことができました。 Amazon Rekognition を組み込んだ電子帳票画面 照合 NG 時には画像のポップアップが表示されたのち (画像左) 照合 NG 部分が赤字で強調表示されて作業者に確認を促す (画像右) 導入効果 Amazon Rekognition の TextDetection を用いることで、フォントや文字の形状変化に左右されずに照合が可能となりました。検証段階では目標水準の読取精度を達成し、人の作業をサポートする品質を満たしていました。また、OCR ソフトでの読取が難しかった低解像度の IJP (インクジェットプリンタ) の文字も高精度に読み込むことができました。 1.5 mm × 2.5 mm の IJP 文字を高精度に読込可能 さらに、機能が API 化されているため、AWS 上に構築した電子帳票アプリへの組み込みが容易であったことも採用のポイントです。API の利用は 1 日に 100 回程度であり、組み込みの OCR ソフトを購入するよりもコストパフォーマンスが高いというメリットもありました。 製品に印字された賞味期限を Amazon Rekognition で読み取り、印字するべき賞味期限との照合をサポートすることで、人が見落としてしまうような賞味期限の設定間違いに対する照合品質が向上しました。また、読取文字列をテキストデータとして記録することで、記録の検索性も向上しました。 今後の展望 Amazon Rekognition で読み取れるフォントが想像以上に幅広であり、食品の製造業務で課題となっている食品原材料の荷姿外装からの使用期限の読み取りへの活用も検討中です。味の素食品株式会社は、今後も AI やクラウドサービスの活用を推進し、食品業界におけるイノベーションを続けます。 ソリューションアーキテクト 長谷川 大

本投稿は 2024 年 11 月 18 日に AWS Machine Learning Blog に投稿された Build cost-effective RAG applications with Binary Embeddings in Amazon Titan Text Embeddings V2, Amazon OpenSearch Serverless, and Amazon Bedrock Knowledge Bases &nbsp;を翻訳したものです。 本日、 Amazon Bedrock Knowledge Bases と Amazon OpenSearch Serverless における Amazon Titan Text Embeddings V2 用のバイナリ埋め込みの提供開始を発表できることを嬉しく思います。Amazon Bedrock でのバイナリ埋め込みと OpenSearch Serverless でのバイナリベクトルストアのサポートにより、Amazon Bedrock Knowledge Bases でバイナリ埋め込みとバイナリベクトルストアを使用した Retrieval Augmented Generation (RAG) アプリケーションを構築し、メモリ使用量と全体的なコストを削減することができます。 Amazon Bedrock は、主要な AI 企業が提供する様々な高性能な 基盤モデル (foundation models – FMs) にアクセスして使用するための単一の API を提供する完全マネージド型サービスです。Amazon Bedrock は、セキュリティ、プライバシー、責任ある AI を備えた 生成 AI アプリケーションを構築するための幅広い機能も提供します。Amazon Bedrock Knowledge Bases を使用することで、FM やエージェントは RAG のために企業の非公開データソースから文脈的な情報を取得することができます。RAG は、基盤モデルがより関連性が高く、正確で、カスタマイズされた応答を提供するために役立ちます。 Amazon Titan Text Embeddings モデルは、ドキュメント、段落、文章の意味的表現を生成します。Amazon Titan Text Embeddings は、テキスト本文を入力として受け取り、1,024 (デフォルト)、512、または 256 次元のベクトルを生成します。Amazon Titan Text Embeddings は、高速な検索向けの、低レイテンシを重視したエンドポイントの呼び出し (検索ステップ中での利用を推奨) と、高速なインデックス作成のための、スループットを重視したバッチジョブを通じて利用可能です。Binary Embeddings により、Amazon Titan Text Embeddings V2 は、データを各次元ごとに単一のバイナリ桁 (0 または 1) としてエンコードした、バイナリベクトルとして表現します。このバイナリ表現により、高次元のデータは、格納と計算においてより効率的な形式に変換されます。 Amazon OpenSearch Serverless は、Amazon OpenSearch Service の serverless デプロイメントオプションです。OpenSearch Serverless は、k-nearest neighbor (kNN) プラグインを使用してインタラクティブなログ分析、リアルタイムアプリケーションモニタリング、Web サイト検索、およびベクトル検索を簡単に実行できる完全マネージド型サービスです。exact および approximate nearest-neighbor アルゴリズムと、複数のストレージおよびマッチングエンジンをサポートしています。基盤となるインフラストラクチャを管理することなく、最新の機械学習 (ML) を活用した検索体験、生成 AI アプリケーション、および分析ワークロードを簡単に構築することができます。 OpenSearch Serverless kNN プラグインは、32 ビット浮動小数点ベクトル (FP32) に加えて、16 ビット (FP16) およびバイナリベクトルをサポートするようになりました。kNN ベクターフィールドタイプを binary に設定することで、Amazon Titan Text Embeddings V2 によって生成されたバイナリベクトルを低コストで保存できます。ベクトルは PUT および GET API を使用して OpenSearch Serverless に保存・検索が可能です。 この投稿では、Amazon Titan Text Embedings、Amazon Bedrock Knowledge Bases、および OpenSearch Serverless 全体にわたる新しいバイナリベクトルサポートの利点をまとめ、開始方法に関する情報を紹介します。以下の図は、Amazon Bedrock Knowledge Bases と Amazon OpenSearch Serverless を使用した概略的なアーキテクチャ図です。 OpenSearch Serverless と Amazon Bedrock Knowledge Bases において、検索品質の低下を最小限に抑えつつ、レイテンシーを短縮し、ストレージコストとメモリ要件を削減することができます。 私たちはバイナリ埋め込みを用いて、Massive Text Embedding Benchmark (MTEB) retrieval data set を実行しました。retrieval data set においては、ストレージを削減しつつ、レイテンシーを 1/25 に短縮する効果がみられました。バイナリ埋め込みは、最大精度 (float32) 埋め込みを使用した結果に対して、再ランキングありで 98.5%、再ランキングなしで 97% の正確性を維持しました。end-to-end RAG ベンチマークにおいては、Amazon Titan Text Embeddings V2 のバイナリ埋め込みは、最大精度埋め込みと比較して、再ランキングありで 99.1%、再ランキングなしで 98.6% の正確性を維持しました。お客様の環境でも、Amazon OpenSearch Serverless と Amazon Titan Text Embeddings V2 のバイナリ埋め込みを使用して、独自にベンチマークを実施することをお勧めします。 Hierarchical Navigable Small Worlds（HNSW）アルゴリズムにおいてバイナリベクトルを使用した OpenSearch Serverless のベンチマークでは、検索用の OpenSearch Computing Units (OCUs) が 50% 削減され、ユーザーのコスト削減につながることが明らかになりました。バイナリインデックスの活用により、検索時間が大幅に短縮されました。従来の検索方法は、リソースを大量に消費する可能性のある L2 距離やコサイン距離などの計算集約的な計算に依存することが多いですが、Amazon OpenSearch Serverless のバイナリインデックスは、より効率的なアプローチであるハミング距離を使用して検索を実行します。 以下のセクションでは、Amazon Titan Text Embeddings での バイナリ埋め込み、ベクトルエンジンにおけるバイナリベクトル (および FP16) と、 Amazon Bedrock Knowledge Bases での binary embedding オプションの使用方法について説明します。Amazon Bedrock Knowledge Bases の詳細については、「 ナレッジベースは、Amazon Bedrock でフルマネージド型の RAG エクスペリエンスを提供するようになりました 」をご覧ください。 Amazon Titan Text Embeddings V2 で Binary Embeddings を生成する Amazon Titan Text Embeddings V2 は現在バイナリ埋め込みをサポートしており、100 以上の言語のテキストサポートを備え、異なる次元サイズ (1024、512、256) における検索性能と精度が最適化されています。デフォルトでは、Amazon Titan Text Embeddings モデルは Floating Point 32 bit (FP32) 精度で埋め込みを生成します。1024 次元の FP32 埋め込みベクトルを使用することで、より良い精度を達成できますが、検索ユースケースではストレージ要件と関連コストも増大します。 コードでバイナリ埋め込みを生成するには、 Amazon Titan Text Embeddings V2 への invoke_model API リクエストに適切な embeddingTypes パラメータを追加します。 import json import boto3 import numpy as np rt_client = boto3.client("bedrock-runtime") response = rt_client.invoke_model(modelId="amazon.titan-embed-text-v2:0", body=json.dumps( { "inputText":"What is Amazon Bedrock?", "embeddingTypes": ["binary","float"] }))['body'].read() embedding = np.array(json.loads(response)["embeddingsByType"]["binary"], dtype=np.int8) 上記のリクエストのように、バイナリ埋め込みのみ、またはバイナリと fp32 の両方の埋め込みを要求することができます。得られる埋め込みは、以下のような 1024 の要素からなるバイナリベクトルです。 array([0, 1, 1, ..., 0, 0, 0], dtype=int8) 詳細とサンプルコードについては、 Amazon Titan Embeddings Text を参照してください。 Binary Vector Embeddings で Amazon Bedrock Knowledge Bases を設定する Amazon Bedrock Knowledge Bases を使用して、1 行もコードを書かずに、Amazon Titan Text Embeddings V2 の Binary Embeddings と Amazon OpenSearch Serverless のバイナリベクトルおよび Floating Point 16 bit (FP16) を利用することができます。以下の手順に従って作業を行ってください。 Amazon Bedrock コンソール で knowledge base を作成します。名前と説明を含む knowledge base の詳細を入力し、関連する AWS Identity and Access Management &nbsp;(IAM)権限を持つ新規または既存のサービスロールを作成または使用します。サービスロールの作成については、 Service roles を参照してください。 Choose data source で、以下のスクリーンショットのように Amazon S3 を選択します。 Next を選択します。 データソースを設定します。名前と説明を入力します。ソース S3 URI を定義します。 Chunking and parsing configurations で、 Default を選択します。続行するには Next を選択します。 埋め込みモデルを選択して knowledge base のセットアップを完了します。このチュートリアルでは、Titan Text Embedding v2 を選択します。 Embeddings type で Binary vector embeddings を選択します。 Vector dimensions で 1024 を選択します。 Quick Create a New Vector Store を選択します。このオプションは、binary データ型をサポートする新しい Amazon OpenSearch Serverless ストアを設定します。 作成後に knowledge base の詳細を確認して、データソースの同期ステータスを監視できます。同期が完了したら、knowledge base をテストして基盤モデルの応答を確認できます。 まとめ この投稿で説明したように、バイナリ埋め込みは Amazon Bedrock で利用可能な Amazon Titan Text Embeddings V2 モデルのオプションであり、OpenSearch Serverless のバイナリベクトルストアも利用できます。これらの機能により、Amazon Bedrock と OpenSearch Serverless のメモリとディスク需要が大幅に削減され、RAG ソリューションの OCU が少なくなります。また、パフォーマンスが向上し、レイテンシーも改善されますが、full float データ型 (FP32) を使用した場合と比較して結果の精度にある程度の影響があります。精度の低下は最小限ですが、アプリケーションに適しているかどうかを判断する必要があります。具体的な利点は、データ量、検索トラフィック、ストレージ要件などの要因によって異なりますが、この投稿で説明した例は潜在的な価値を示しています。 Amazon Open Search Serverless、Amazon Bedrock Knowledge Bases、および Amazon Titan Text Embeddings v2 でのバイナリ埋め込みサポートは、既にこれらのサービスが提供されている全ての AWS リージョン で本日から利用可能です。詳細と今後の更新については Region list をご確認ください。Amazon Knowledge Bases の詳細については、 Amazon Bedrock Knowledge Bases 製品ページをご覧ください。Amazon Titan Text Embeddings の詳細については、 Amazon Titan in Amazon Bedrock をご覧ください。Amazon OpenSearch Serverless の詳細については、 Amazon OpenSearch Serverless 製品ページをご覧ください。価格の詳細については、 Amazon Bedrock の料金 &nbsp;ページをご確認ください。 今すぐ Amazon Bedrock コンソールで新機能をお試しください。Amazon Bedrock に関するフィードバックは AWS re:Post または通常の AWS の連絡先を通じてフィードバックを送信してください。また、 community.aws で生成 AI ビルダーコミュニティにもご参加ください。 著者について Shreyas Subramanian はプリンシパルデータサイエンティストです。生成 AIと深層学習を用いた AWS サービスの活用による、お客様の事業課題を解決支援を行っています。大規模な最適化と ML、ML と強化学習を用いた最適化タスクの加速といった分野の経験を持っています。 Ron Widha は、Amazon Bedrock Knowledge Bases のシニアソフトウェア開発マネージャーです。簡単に拡張可能な RAG アプリケーションを構築できるよう、お客様を支援しています Satish Nandi は、Amazon OpenSearch Service のシニアプロダクトマネージャーです。OpenSearch Serverless に注力しており、ネットワーキング、セキュリティ、AI/ML の分野で長年の経験を持っています。コンピューターサイエンスの学士号とアントレプレナーシップの MBA を取得しています。余暇は、飛行機や ハンググライダーの操縦、バイクに乗ることを楽しんでいます。 Vamshi Vijay Nakkirtha は、OpenSearch Project と Amazon OpenSearch Service に従事しているシニアソフトウェア開発マネージャーです。主な関心事は分散システムです。

この記事は Optimize compute resources on Amazon ECS with Predictive Scaling (記事公開日 : 2024 年 11 月 21 日) の翻訳です。 導入 Amazon Elastic Container Service (Amazon ECS) は、AWS と深く統合され、簡単に利用可能なコンテナオーケストレーションサービスです。Amazon ECS は、あらゆる規模のコンテナアプリケーションのデプロイと管理を効率化します。Amazon ECS のリソースを効率的に管理する上で重要な機能の 1 つに、 サービスオートスケーリング があります。この機能を利用すると、 ECS サービス のタスク数を自動的に調整し、アプリケーションの需要の変化に効率的に対応することができます。 Amazon ECS と Application Auto Scaling の統合により、ターゲット追跡ポリシーまたはステップスケーリングポリシーを使用して、 Amazon CloudWatch メトリクスに基づく ECS サービスのオートスケーリングを設定できます。例えば、平均 CPU 使用率やターゲットあたりのリクエスト数、あるいはキューの深さなどの自分で設定した カスタムメトリクス に基づいてタスク数を自動で増減させることができます。また、スケジュールスケーリングを使用すると、予測可能なトラフィックパターンに対して、特定の時間にタスク数を増減させるプロアクティブなスケーリングを実現できます。 本日、Amazon ECS サービスオートスケーリングの新しいスケーリングポリシーである「 予測スケーリング 」を発表できることを嬉しく思います。このポリシーは、高度な機械学習 (ML) アルゴリズムを用いて需要の急増を予測するように設計されています。予測スケーリングでは、予測に基づいて前もってタスク数を増加させることでアプリケーションの可用性と応答性を向上させると同時に、過剰なプロビジョニングを削減することでコスト削減を実現します。このポリシーはターゲット追跡ポリシーやステップスケーリングポリシーと併用可能なため、リアルタイムの情報と過去のパターンの両方に基づいて、アプリケーションをスケールできます。この記事では、予測スケーリングの概要を説明し、この機能が役立つ場面や実際に予測スケーリングを設定する手順について解説します。 Amazon ECS における予測スケーリング ECS サービスのスケーリングにおいて、ターゲット追跡ポリシーとステップスケーリングポリシーは効果的ですが、これらは需要の変化を検出した後に動作するリアクティブなポリシーです。このことは、通常、緩やかな需要の変化に対しては大きな問題になりません。しかし、早朝の業務開始時のスパイクのように需要が急激に変化する場合、このようなリアクティブなスケーリングでは、スケーリングアクションが開始され、最適なキャパシティを確保するまでに時間がかかる可能性があります。初期化に時間がかかるアプリケーションの場合には、この時間がさらに長引く可能性があり、需要が急激に変化した際、一時的なパフォーマンス低下を引き起こす可能性があります。 その対策として、一部の利用者は、使用量のメトリクスに対して理想的な値よりも低い閾値を設定し、タスクをオーバープロビジョニングしています。これにより、トラフィックの急増に対応するためのタスクを余分に確保し、スケールアウト時の遅延を相殺します。また、利用者の中には、スケジュールスケーリングを使用して、予測される需要パターンに基づいたスケーリングを手動で設定している方もいます。しかし、スケジュールスケーリングを効果的に活用するには、トラフィックパターンとそれに対応するためのタスク数を手動で特定する必要があります。また、時間の経過とともにトラフィックパターンは変化するため、スケーリングの設定を定期的に調整する必要があります。そのため、実際の需要に対してリソースを最適化し、パフォーマンスの向上と運用コストの削減を実現するために、より効率的かつプロアクティブなスケーリングソリューションが必要とされています。 予測スケーリングを利用することで、需要の急増を予測して、前もってアプリケーションをスケールできるようになります。このアプローチにより、需要が増加する前に、新しいタスクを初期化するための時間を確保できます。予測スケーリングでは、高度な機械学習アルゴリズムを用いて、数百万のデータポイントからアプリケーション固有の需要パターンを継続的に学習することで、時間とともに、より正確な予測とカスタマイズされたスケーリング体験を提供します。このソリューションは、他のリアクティブなスケーリングポリシーと並行して機能するため、予測した需要変化とリアルタイムのメトリクスの両方を考慮した、より高い可用性を実現します。また、予測スケーリングは、予測に基づいたスケールインを実施しません。これは、予期せず需要が急増した際にも、必要なキャパシティを維持するのに役立ちます。スケールインについては、リアクティブなスケーリングポリシーまたはスケジュールスケーリングを利用してください。具体的には、Amazon ECS で予測スケーリングを使用する場合、以下のようなシナリオが想定されます。 複数のスケーリングポリシー (予測スケーリングとターゲット追跡スケーリングなど) を有効化した場合、それぞれが独立して必要なタスク数を見積もります。それぞれの見積もりの最大値が、最終的なタスクの必要数になります。 現在のタスク数が予測したタスクの必要数よりも少ない場合には、Amazon ECS はこれらの値が等しくなるように ECS サービスをスケールアウトします。 現在のタスク数が予測したタスクの必要数を上回っている場合には、Amazon ECS はサービスをスケールインしません。これは、実際に必要な値よりも少ない値を予測した場合にスケールインするのを防ぎ、常に必要なキャパシティを確保できるようにするためです。予測スケーリングと (ターゲット追跡ポリシーなどの) リアクティブなスケーリングポリシーの両方が、現在のタスク数よりも少ない値を見積もった場合にのみ、ECS サービスはスケールインします。 予測したタスクの必要数が、ECS サービスオートスケーリングにおけるタスクの最大数を上回っていて、かつこの上限を無視するオプションを選択している場合、ECS サービスオートスケーリングはその上限を超えてタスクを追加できます。この上限を無視するオプションを選択していない場合には、ECS サービスオートスケーリングは、これらの範囲を超えてスケールすることはありません。 予測スケーリングに関する推奨事項 予測スケーリングは、一貫したパターンに基づいて需要が急激に変化するアプリケーションに最適です。これには、ユーザーが特定の時間に利用開始することで急激なスパイクが発生するような日次や週次のパターンを持つユーザー向けのアプリケーションや、業務時間のパターンに従うような CI/CD ツールなどの社内アプリケーションが含まれます。リアクティブなスケーリングポリシーは、このような急激なスパイクに対して、通常、何回かに分けてスケーリングアクションを実行するため、最適なキャパシティを確保するまでに時間がかかります。この時間は、ロードバランサーへのタスクの登録やアプリケーションの起動、またデータレプリケーションなどの初期化ステップによって、さらに長引く可能性があります。また、予測スケーリングは、リアクティブなスケーリングポリシーが不適切なタイミングでスケールインしようとした際のセーフティネットとしても機能します。例えば、リアクティブなスケーリングポリシーが唯一考慮するリアルタイムのメトリクスは、差し迫った需要の急増を反映していなかったり、デプロイメントや障害などの影響を受けている可能性があります。具体的なユースケースを探るために、以下の例を考えてみましょう。 ワークロードは周期的なトラフィックパターンに従い、業務時間中はリソース使用量が増加し、夕方や週末には使用量が減少するという特徴を持つとします。このようなワークロードでは、予測スケーリングを用いてベースラインを設定することで、機械学習アルゴリズムを使用して過去のパターンを認識し、リソースをプロアクティブに管理できます。加えて、急激なスパイクに対しては、リアクティブなポリシーを併用して対処することが推奨されます。 ワークロードは、2 時間毎などの特定の時間感覚でオン/オフを繰り返すとします。このベースラインはスケジュールスケーリングで管理できますが、定期実行されるジョブの設定を定期的に分析し、スケーリングの設定を手動で調整する必要があります。予測スケーリングを使用すると、このプロセスを自動化し、手作業の必要性を減らし、適切な間隔で効率的なスケーリングを実現できます。 また、初期化に時間がかかるワークロードでは、リアクティブな方法で需要の変化に対応するのが難しくなります。初期化の時間は、特に営業日の業務開始時のような需要の急増において、最適化なキャパシティを確保するまでの時間に遅延をもたらします。また、大量の依存関係や静的なアセットを持つアプリケーションでは、これらの初期化の時間はさらに長引くことが想定されます。特定の時間パターンを示し、長い初期化プロセスを持つアプリケーションの場合には、予測スケーリングを設定することで、需要の変化に迅速に対応することが可能になります。 予測スケーリングの利用方法 予測スケーリングは、現在のオートスケーリングの動作を邪魔することなく利用開始できます。予測スケーリングポリシーには、「予測のみ」と「予測およびスケール」の 2 つのモードがあります。「予測のみ」モードでは、キャパシティの予測を生成するものの、実際にはスケーリングを実施しないため、普段の需要パターンを正確に予測できているか確認することができます。このモードは、本番環境の既存のスケーリング動作に影響を与えないため、予測スケーリングを初めて利用する際に最適です。 さらに、「予測のみ」モードで複数のポリシー (異なるメトリクスやターゲット値に基づいたポリシーなど) を作成することで、異なる設定を比較することができます。予測の精度を確認した後は、アプリケーションに最適なポリシーを選択して、「予測およびスケール」モードに移行できます。このモードに移行すると、予測スケーリングは積極的にスケーリングに関する意思決定を行い、予測される需要のスパイクに対して効果的に対応できるようになります。 ウォークスルー このセクションでは、これまで説明した予測スケーリングについて、その設定と構築に必要な手順を詳細に説明します。新しい ECS サービスを使用する場合は、予測を生成するために少なくとも 24 時間分のデータが必要です。また、予測の精度はデータが多いほど向上するため、理想的には 2 週間分のデータがあると望ましいです。 予測スケーリングや ECS サービスオートスケーリングを使用する前に、適切な使用量メトリクスとターゲット値を確認してください。例えば、計算負荷の高いアプリケーションであれば、CPU 使用率などが候補になります。最適な設定を見つけるには、ステージング環境で負荷試験を実施するのが良いでしょう。詳細は、 Amazon ECS 開発者ガイド を参考にしてください。すでにターゲット追跡またはステップスケーリングを設定している場合は、予測スケーリングにも同じメトリクスを使用してください。また、メトリクスのターゲット値を調整することで、パフォーマンスとコストのバランスを制御します。「予測のみ」モードを使用することで、現在の構成に影響を与えることなく、設定を調整できます。 1. ECS コンソールでは、新しく導入された「サービスの自動スケーリング (Service auto scaling)」タブを使用して、ECS サービスのスケーリングポリシーを確認、設定できるようになりました。ECS サービスの作成時にオートスケーリングを設定していない場合は、このタブからオートスケーリングを有効化できます。このウォークスルーでは、すでにターゲット追跡ポリシーを CPU 使用率 (60%) に対して有効化していると仮定して、そこに予測スケーリングを設定する方法を確認します。まず、「スケーリングポリシーを作成 (Create scaling policy)」をクリックし、予測スケーリングポリシーを作成しましょう。 図 1 : ECS サービスのオートスケーリング設定画面 2. 以下の設定例では、ECS サービスの事前定義済みのメトリクスである (平均) CPU 使用率を選択しています。追加設定の「起動前のキャパシティ (Pre-launch capacity)」から SchedulingBufferTime 属性を 600 秒に設定することで、スケールアウトアクションを (1 時間単位で) 予測した時刻の 10 分前に開始するように設定できます。 図 2 : 予測スケーリングの作成 最初は「予測のみ」モードを選択することをオススメします。これにより、実際に利用開始する前に、予測の精度と適合性を評価できます。 図 3 :「予測のみ」モードと「予測とスケール」モード 注 : 予測スケーリングは、ECS サービスの作成/更新画面からは設定できません。予測スケーリングを設定するには、ECS サービスを作成後、サービスの「サービスの自動スケーリング (Service auto scaling)」タブを使用してください。 3. 「予測のみ」モードで少なくとも 2 つのポリシーを持つことで、異なるメトリクス値を使用するポリシーを比較評価できます。ステップ 2 に戻って、異なるメトリクス値で予測スケーリングを設定してみましょう。例えば、以下のように複数のポリシーを設定できます。 図 4 : 複数の予測スケーリングポリシーの設定 4. ポリシーを作成すると、予測スケーリングは最大 14 日間の過去データを分析し、この先の 48 時間に対して 1 時間単位で予測を生成します。これらの予測は、6 時間ごとに CloudWatch の新しいデータで更新され、時間とともに精度が向上します。 5. 一定時間が経過すると、「レコメンデーション」タブでは、予測スケーリングポリシーに関する推奨事項が表示されます。ここでは、そのポリシーを使用することによるコストと可用性への影響を確認できます。これらの分析は、オートスケーリングの設定を最適化するのに役立ちます。また、すべてのポリシーが「予測のみ」モードで存在する場合、より高い可用性を低いコストで実現するポリシーに対して、「最適 (Best prediction)」タグが付与されます。「最適」としてタグ付けされたポリシーを、そのまま「予測およびスケール」モードに移行させることができます。 注 : 予測スケーリングの予測と推奨事項にアクセスするには、追加の IAM 権限 ( application-autoscaling:GetPredictiveScalingForecast ) が必要です。 図 5 : 予測スケーリングポリシーに関する推奨事項 6. 「チャートを表示 (View chart)」をクリックすると、実際のデータと予測値を比較して、予測モデルの精度を評価することができます。 図 6 : 予測スケーリングの実測値と予測値 (左 : 負荷、右 : キャパシティ) 7. 以下の ECS コンソール画面の例のように、予測スケーリングと動的なスケーリング (ターゲット追跡) ポリシーを組み合わせることで、ECS サービスを効果的にスケールできます。予測スケーリングはベースラインのキャパシティとして利用され、動的なスケーリングは現在の使用状況に基づいて追加のキャパシティを調整します。Amazon ECS は、スケジュールスケーリングを除いたすべてのポリシーが推奨するタスク数をそれぞれ計算し、その最大値をもとにスケーリングを実施します。 図 7 : 予測スケーリングと動的なスケーリングを組み合わせた設定 8. 「スケーリングアクティビティ (Scaling activity)」セクションでは、過去のスケーリングに関する詳細なビューが提供され、スケーリングポリシーの動作に関する洞察を得ることができます。 図 8 : ECS サービスのスケーリングアクティビティ一覧 まとめ 新しく導入された予測スケーリングは、リアクティブなスケーリングと組み合わせることで、予測した需要変化とリアルタイムのメトリクスに対応して、必要な数のタスクを確実に実行できるように機能します。これにより、可用性と応答性の高いアプリケーションを構築しながら、リソースを効率的に使用してコストを最適化できます。 予測スケーリングを利用開始する際は、まずは「予測のみ」モードを有効化して、実際にはスケーリングを行わず、予測したキャパシティについて可視化するところから始めましょう。これをもとに、適切なメトリクスを検討し、適切なターゲット値を調整することで、予測スケーリングポリシーを改善します。準備が完了したタイミングで「予測およびスケール」モードに移行し、予測したキャパシティに基づいて、ECS サービスをプロアクティブにスケールさせることができます。 この機能についてさらに詳しく知りたい方は、 Amazon ECS 開発者ガイドの予測スケーリングに関するセクション を参照してください。Amazon ECS コンソール、AWS SDK、または AWS CLI を使用して、ECS サービスの予測スケーリングを設定できます。 AWS コンテナサービスロードマップ にて、皆様からのフィードバックや提案をお待ちしています。

AWS re:Invent 2024 のカウントダウンが始まりました。2024年12月2日月曜日より、5日間にわたる恒例のイベントが米国ネバダ州ラスベガスで開幕します。 re:Invent 2024 では、AWS のリーダーによる 基調講演 が行われ、最新のクラウドと生成 AI（人工知能）のイノベーションが紹介されます。参加者は、テクノロジーのデモンストレーション、顧客およびパートナーによる セッション 、ゲーム化された学習イベントなど、盛りだくさんの Expo フロアを堪能することができます。 また、2024年12月2日午後7時（PST）からの「 Visionaries in the Stadium kick-off event 」や、2024年12月5日午後7時30分（PST）からの「 re:Play party 」など、ネットワーキングの機会も数多く用意されています。 AWS for Games の多彩なプログラムは、ゲーム業界における最大のトレンドや課題について活発な議論を促すように企画されています。セッションでは、Roblox、Riot Games、PUBG Studios、Epic Games、Supercell、Zynga、Hard Rock Digital などの AWS for Games のお客様が AWS サービスを活用してゲームやビジネスを拡張し、進化させている方法について詳しく説明します。 ゲーム業界のプロフェッショナルは、ベネチアンホテルの展示会場にある「AWS for Industries Pavilion」（580ブース）を訪れ、ゲームの未来を形作る AI ツールやその他のテクノロジーを実際に体験することができます。AWS for Games に関する多数のセッション、チョークトーク、ワークショップが予定されているため、私たちのチームでは、 re:Invent に参加するゲーム業界のお客様向けの厳選ガイド をまとめました。 これには、12月2日午後1時30分（PST）に開催される イノベーションセッション 「 MAE203-INT: Reinventing Entertainment 」も含まれます。このセッションは、AWS の Media &amp; Entertainment (M&amp;E), Games, and Sports のゼネラルマネージャーである Samira Panah Bakhtiar が担当します。 以下に、時系列順のハイライトとなるプログラムの一覧を記載します。また、まだの方は今すぐ AWS re:Invent に登録 してください。セッションタイトルの前に GAM と記載されているものは、AWS for Games re:Invent トラックの一部であることを示しています。 2024年12月2日(月曜日)&nbsp; (以下全て太平洋標準時(PST)で表記) 注目すべき講演者には、Riot Games Sr. Principal Software Engineer の Brian Miller 氏、Zynga Principal Software Engineer の Chris Vodak 氏および Engineering Manager の Ardrian Hardjono 氏、Supercell Sr. Cloud Governance Engineer の Toni Syvanen 氏、Epic Games Technical Director の Mattias Jansson 氏などが含まれます。AWS のエキスパートがリードするチョークトーク、ワークショップ、セッションでは、AI の活用による開発者の生産性向上やプレイヤー体験の改善など、さまざまなトピックを取り上げます。 9:00 AM – 10:00 AM: GAM307 : Effortless game launches: How League of Legends runs at scale on AWS 10:00 AM – 11:00 AM: GAM 305 : How generative AI can boost developer productivity &amp; player experience 10:30 AM – 11:30 AM: GAM308 : How Star Wars: Hunters got to the next level with Amazon GameLift 12:30 PM – 2:30 PM: GAM301-R : Build a scalable cross-platform multiplayer game backend on AWS 1:00 PM – 2:00 PM: GAM309 : How Supercell’s newest game launched with tens of millions of players 1:30 PM – 2:30 PM: GAM304-R/304-R1 : Cloud game development toolkit 1:30 PM – 2:30 PM: MAE203-INT : Reinventing Entertainment 2:30 PM – 3:30 PM: DAT336-S : How Hard Rock Digital built a multi-region sportsbook with CockroachDB (sponsored by CockroachDB) 2024年12月3日(火曜日)&nbsp;&nbsp; 以下のおすすめセッションのプログラムのハイライトでは、幅広いトピックを取り上げ、Epic Games の Technical Director である Mattias Jansson 氏と Roblox の Principal ML Engineer である Denis Goupil 氏によるプレゼンテーションが予定されています。また、AWS for Games のチョークトークでは、フルマネージドのグローバルゲームサーバーホスティングソリューションである Amazon GameLift の機能、アーキテクチャパターン、ベストプラクティスについて学ぶことができます。 10:30 AM -10:50 AM : GAM312: Scaling GPU infrastructure and using LLMs for Roblox’s metaverse 11:30 AM – 12:30 PM : CDN308: Amazon CloudFront: Enhancing web performance one HTTP request at a time 1:30 PM – 2:30 PM : GAM302-R: Host multiplayer games on Amazon GameLift with containers and anywhere 2:30 PM – 3:30 PM : DEV332: From chatbots to gamebots: Exploring AI’s potential in video games 3:00 PM – 4:00 PM : CMP338: Generative AI-enabled 3D avatar assistants on AWS 4:00 PM – 5:00 PM : CMP342: Scaling 3D content creation with open-source technologies 4:30 PM – 5:30 PM : GAM306: Scaling Epic’s Unreal Engine on AWS with Linux containers 2024年12月4日(水曜日)&nbsp;&nbsp; Roblox の Sr.Technical Director である Ivan Marcin 氏が、Amazon Bedrock を使用したマルチモーダルエージェントの構築方法を参加者に紹介する画期的なセッションを再び開催します。ゲームのプロフェッショナルは、ゲームのコンセプトストーリーボードの構築に生成AIを利用する方法を学ぶワークショップにも参加できます。 8:30 AM – 9:30 AM : GAM310: Scaling generative AI models for millions of users in Roblox 12:30 PM – 2:30 PM : GAM 303: Upgrade your game storyboards with multimodal prompt chaining 1:30 PM – 2:30 PM : GAM302-R1: Host multiplayer games on Amazon GameLift with containers and anywhere 2:30 PM – 3:30 PM : HYB307: Delivering low-latency applications at the edge 2024年12月5日(木曜日)&nbsp;&nbsp; 木曜日のプレゼンテーションでは、AWS Game Backend Framework の使い方を説明し、AWS アーキテクチャを進化させて、世界中で何百万人もの同時ゲームユーザーに対応する方法を紹介します。 11:30 AM – 12:30 PM: ANT344: Cost-effective data processing with Amazon EMR 12:30 PM – 2:30 PM: GAM301-R1: Build a scalable cross-platform multiplayer game backend on AWS 3:30 PM – 4:30 PM:&nbsp; GAM311: The evolution story of game architecture: PUBG: Battlegrounds, Krafton iOS または Android で AWS Events アプリをダウンロードすると、re:Invent で展示されるすべてのプログラム、ワークショップ、サービスを調べたり、重要なセッションの最新情報を入手したり、イベントを検索したりすることができます。 イベントまでの最新情報は、 AWS for Games ブログ および AWS for Games on LinkedIn をご覧ください。ラスベガスでお会いできることを楽しみにしています！ この記事は Level up game development insights at AWS re:Invent 2024 を翻訳したものです。翻訳はソリューションアーキテクトの鷲見が担当しました。

こんにちは。AWS マーケティング統括本部です。 2024 年 10 月 31 日、AWS AI Day が開催されました。本イベントでは、生成 AI の実用化に興味があるビジネス、テック、デベロッパーの皆様を対象に、生成 AI の実用化に向けた AWS の技術動向、お客様による活用事例の取り組みが紹介されました。会場またはオンラインでご参加いただいた皆様に改めて御礼申し上げます。 当日のセッション動画および資料が公開されておりますので、是非学習にお役立てください。（当日のタイムテーブル） アーカイブは こちら 基調講演 基調講演では、AWS が提供する生成 AI サービスの概要と支援、それらを活用して業務で実活用するためのアプリケーション構築方法について、生成 AI ジャーニーの各フェーズ(ユースケース選定、モデル選択、責任ある AI、カスタマイズ、アプリ運用)に沿って、AWS 安田、大渕が紹介しました。お客様事例では、三井物産株式会社 稲垣氏より生成 AI を活用した入札業務の効率化、株式会社Poetics 山崎氏より商談内容の記録と解析への活用について詳しく紹介があり、どちらの事例でも業務作業時間が大幅に削減できたことが強調されていました。また、Anthropic Frances 氏、Meta Hamid 氏も登壇し、最適なモデルサイズやオープンソースとしてのモデル提供の意義などについて語られました。 ビジネスリーダー向けトラック 本トラックでは、生成 AI の企業活用と、その際の課題解決や責任ある AI 実現に向けた取り組みについて 3 つのセッションが行われました。西日本電信電話株式会社 中井氏からは、グループ社員 3 万人に AI アシスタントを導入した取り組みについて、導入時の課題や工夫、ユーザーの反応などが紹介されました。株式会社ペライチ 安井氏からは、AI による Web ページ自動生成サービスの提供と、それによる中小企業のデジタル化への課題を解決する取り組みについて紹介がありました。最後に、AWS セキュリティエキスパートである吉田と保里が、生成 AI のセキュリティ対策と倫理的な利用について、各国の規制動向や AWS サービスで実践している責任ある AI について紹介しました。 テクニカルリーダー、デベロッパー向けトラック 本トラックでは、生成 AI を PoC の次のステップに進めるにはどうしたら良いか、をテーマに 3 つのセッションが行われました。AWS 石見からは、コンテンツ審査を題材とした生成 AI をプロダクトに実装する際の考慮点と具体的な対策(LLMと従来の棲み分け、精度改善、コスト最適化、可用性・スループット、速度、LLMOps)について解説がありました。株式会社セゾンテクノロジー 有馬氏、石原氏からは、自社サービスに関する AI アシスタントを Generative AI Use Cases JP(GenU) を活用して構築した事例が紹介されました。既存の高精度 RAG システムの活用や Amazon CloudWatch Dashboard を用いた対話分析ダッシュボード、情報の最新化方法など、様々な工夫が紹介されました。最後に、AWS 片山からは生成 AI アプリケーション開発におけるセキュリティ・コンプライアンスについて、 生成 AI Security Scoping Matrix や OWASP を元にした具体的な対策方法を説明しました。 SaaS 企業、デベロッパー向けトラック 本トラックでは、「SaaS における生成 AI 実装を DiveDeep する」をテーマに、AWS SA からの3つのエキスパートレベルのセッションとお客様による事例セッションが行われました。AWS 赤澤からは、マルチテナント環境下における生成 AI 活用のデザインパターンについてご紹介をしました。AWS 深見からは、RAG における検索基盤にフォーカスし、マルチテナントでの利用に必要な権限分離とユースケースごとの精度指標の考え方についてご説明をしました。AWS 松﨑からは、LLM 特有の脅威と実際の SaaS アプリケーション運用において、技術者が AWS サービスをはじめとした技術でどのような防御が可能かの紹介を行いました。最後に、国内 SaaS ベンダーによる生成 AI 実践事例として、株式会社Works Human Intelligence VP of Technology 加藤 文章 氏から大企業向け SaaS での生成 AI 活用において現実的にできることと課題についてご紹介いただくとともに、株式会社エクサウィザーズ 取締役 坂根 裕 氏から、生成 AI 応用システムのアーキテクチャと表現力をテーマに、デモを交えてセッションを実施いただきました。 [特別企画①] AWS Japan 生成 AI ハッカソン 決勝戦 本ハッカソンは「生成AIを活用して会社の仕事をもっと楽しく、楽に」をテーマに、3週間という限られた時間の中でゼロからアプリ開発を行いました。参加したのは選考を経て最終予選に参加した12組、40名。Amazon Bedrockを使用して開発された興味深い 12 個のアプリが誕生しました。業務効率を大幅に向上させるもの、上司と部下、同僚などの社員どうしのコミュニケーションを円滑化するもの、スキル向上を実現するものなど、その内容はさまざまですが、どれもが使いたくなる「楽しさ」を持っているのが特長です。どれもレベルが高く拮抗し、審査員のみなさんを悩ませましたが、決勝に進出する３組として * 楽しく学べる生成 AI システム「AI Tech Talkers」（アーベルソフト） * 求職者に寄り添い、転職エージェントの工数を削減する「AI 面接エージェントサービス」（パソナPDT） * クリップボードで AI 活用！「Ctrl + Cat」（チーム：mirAI Innovation Center（仮）） が選出されました。 これら 3 組が戦う決勝戦には QuizKnock 伊沢氏、鶴崎氏 がナビゲーターとして登場（お二人は最終予選でも審査員として全発表をつぶさに聞いています）。盛り上がる中にも緊張感のただようステージでは、各組がそれぞれに与えられた持ち時間 4 分間のプレゼンに全力をぶつけます。 見事優勝を勝ちとったのは「mirAI Innovation Center(仮）」（大日本印刷株式会社）の「Ctrl+Cat」。知りたいことをクリップボードに貼り付けて問い合わせるだけで、猫のキャラクターが楽しく教えてくれて、知識が蓄積されていくともに成長するAIアプリです。3週間でこの完成度はすばらしく、審査員の皆さんをうならせていました。 ◯ 緊急企画のお知らせ – 12/17（火）ハッカソン Meetup 開催 このたび、これらの上位入賞作品の技術的な深堀を行うミートアップ「AWS Japan 生成 AI ハッカソン Developer Meetup」を AWS 目黒オフィスにて開催します。優勝作品、準優勝作品を始め、詳細の紹介、デモなどを通じてこれらの作品がどのように作られているのかがわかる貴重な機会です。ぜひご参加ください！ 参加登録は こちら から [特別企画②] グローバルモデルプロバイダから学ぶ 本企画では、Anthropic、Meta の技術者に講演いただき、各社のモデルの特徴や最新情報をお話しいただきました。Anthropic Jason 氏による講演では、Claude 3.5 Sonnet(upgraded) モデルについて Computer Use 機能など詳細を説明し、活用事例や今後のロードマップについても触れました。また、Claude に対する皆様のフィードバックが Anthropic の研究開発にとって重要であることを強調しました。Meta Hamid 氏による講演では、Meta の AI 戦略として、オープンソースで提供する意義について、提供開発者がモデルを自由にトレーニングやファインチューニング、変更できる点などを強調しました。その上で、Llama モデルと Llama Stack の概要、選定すべき理由、Llama 3.2 の新機能などについて説明しました。また、PyTorch と Llama モデルの各種連携について詳細に説明しました。 [特別企画③] AWS ジャパン 生成 AI 実用化推進プログラム 本トラックでは、2024 年 7 月に発表した「 生成 AI 実用化推進プログラム 」をテーマに、プログラムの進捗と参加企業の取り組みについて発表を行いました。このプログラムは生成 AI を活用してビジネス課題を解決することを支援するもので、モデル開発と既存モデル活用の両方をサポートし、戦略策定から本番環境での活用まで支援を提供、総額 1,000 万 USドル規模の AWS クレジットを投資する取り組みです。AWS パートナーとの連携により実用化を加速します。 AWS の小林より、当初想定の50 社を超えた60 社以上がプログラムに参加していること、11月 15 日開催の「Generative AI Frontier Meetup」イベント、プログラムの申し込み期限延長が発表されました。プログラムのモデル利用者参加企業として株式会社テックウェイ 執行役員 滝沢雅広氏、キヤノン IT ソリューションズ株式会社 R&amp;D 本部言語処理技術部 蔵満琢麻氏、モデル開発者から株式会社野村総合研究所 生産革新センター AI ソリューション推進部 エキスパート研究員 岡田智靖氏の 3 名をお迎えし、各社の取り組みについてご紹介いただきました。当初 2024 年 11 月 22 日としていた締め切りが、好評につき 2025 年 2 月 14 日まで延長されましたのでぜひご登録ください。 展示コーナー 展示コーナーでは生成 AI を本番環境で活用されている 100 を超えるお客様の事例や、様々なユースケースを利用できるアプリケーションの GenU、生成 AI 実用化推進プログラムの概要など、7 つの展示を行いました。セッション終了後にも多くの方にお立ち寄りいただき、セッションで触れた内容の詳細や、生成 AI の実装について AWS 社員と会話し、それぞれの生成 AI ジャーニーについて理解を深めていただけました。展示コーナーで展示したコンテンツの一部は以下からアクセスいただけます。 日本の生成 AI 事例集 AWS ジャパン生成 AI 実用化推進プログラム GenU AI/ML に関する新しい AWS 認定 AWS Certified AI Practitioner AWS Certified Machine Learning Engineer – Associate その他参考サイト AWS ジャパン生成 AI 活用支援サイト

Amazon Relational Database Service (Amazon RDS) for SQL Server が、 Amazon Elastic Block Store (Amazon EBS) io2 Block Express ボリュームをサポートするようになりました。これらのボリュームは、高性能、高スループット、そして一貫して低レイテンシーを必要とするあらゆる重要なデータベースワークロードに対応するように設計されています。 io2 Block Express ボリューム は、99.999% の耐久性、最大 64 TiB のストレージ、最大 4,000 MiB/s のスループット、最も要求の厳しいデータベースニーズに対して最大 256,000 の Provisioned IOPS をサポートしており、EBS io1 ボリュームと同じ価格で提供されます。 この投稿では、Amazon RDS for SQL Server DB インスタンスで io2 Block Express ボリュームを使用するためのベストプラクティスを共有します。 io2 Block Express ボリュームを使用した適切な RDS DB インスタンスクラスの選択 RDS DB インスタンスのパフォーマンスは、インスタンスタイプとストレージタイプの組み合わせによって決まります。したがって、RDS DB インスタンスレベルと EBS ボリュームレベルの両方で適用される最大 IOPS とスループットの制限を知ることが重要です。高パフォーマンスなワークロードの場合は、 プロビジョンド IOPS SSD ストレージ (io2) と高性能の DB インスタンスクラスタイプ (X2iedn、R6i、R5b など) を組み合わせることをお勧めします。負荷の低いワークロードの場合は、 汎用インスタンスクラスタイプ (m5i/m6i) とストレージ (gp2/gp3) で十分かもしれません。 ワークロードに最適な組み合わせを決めるには、次の手順を実行してください。 アプリケーションのワークロードの IOPS とスループット要件を特定します。 CPU、メモリー、ネットワークパフォーマンス要件を満たす適切な RDS DB インスタンスクラスを選択します。 IOPS とスループット要件に基づいて、汎用ストレージまたはプロビジョニングされた IOPS ストレージのいずれかの適切なストレージタイプを選択します。 次の図は、IOPS スループット、およびキャパシティの要件に基づいて RDS DB インスタンスストレージの決定ツリーを示しています。 次のいずれかの条件が当てはまる場合は、io2 ボリュームを選択する必要があります。 アプリケーションには高い IOPS (16,000 IOPS 以上) が必要 一貫したパフォーマンスを実現するため、低レイテンシと高スループット (1,000 MiB/s 以上) が必要 ストレージ容量の要件は 16 TiB を超えている アプリケーションには高い耐久性と可用性 (99.999% の耐久性 SLA) が必要 ミッションクリティカルなデータベースまたは高パフォーマンスが持続的に必要なアプリケーションを実行している AWS リージョンでの io2 Block Express ボリュームの可用性を確認するには、この ドキュメント を参照してください。 io2 Block Express ボリュームの組み合わせのパフォーマンスは、選択した RDS DB インスタンスクラスとサイズによって異なります。次の表は、サポートされているさまざまな RDS インスタンスクラスにおける最大の RDS DB インスタンスサイズと、対応する io2 Block Express のパフォーマンス制限を示しています。 DB Instance Class Max throughput limit (MiB) Max IOPS limit (16 KiB I/O) Max DB instance size X2iedn 10,000 260,000 db.x2iedn.32xlarge R5b 7,500 260,000 db.r5b.24xlarge R6i/M6i 5,000 160,000 db.r6i.32xlarge R5d/M5d/Z1d 2,375 80,000 db.r5d.24xlarge db.m5d.24xlarge db.z1d.12xlarge R5/M5 2,375 80,000 db.r5.24xlarge db.m5.24xlarge Amazon RDS for SQL Server でサポートされている DB インスタンスクラスについては、「 Microsoft SQL Server の DB インスタンスクラスサポート 」を参照してください。サポートされているインスタンスレベルのベースラインスループット、最大 IOPS、最大スループットの詳細については、「 Amazon EBS 最適化インスタンス 」を参照してください。 サポートされているインスタンスとボリュームの組み合わせについては、AWS のアップデートと機能強化により制限が変更される可能性があるため、常に最新の AWS ドキュメントを参照してください。 SQL Server データベースの io2 Block Express ボリュームを使用した Amazon RDS への移行 io2 Block Express ボリュームを使用する RDS for SQL Server DB インスタンスへの移行プロセスは、gp2、gp3、io1 などの他のボリュームとよく似ています。主な違いは、io2 ボリュームでは、最大 64 TiB の大規模なデータベースワークロードを移行できることです。オンプレミスまたは Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上で実行されている SQL Server データベースを Amazon RDS for SQL Server に移行する最も一般的な方法は、 Amazon Simple Storage Service (Amazon S3) を使用した SQL Server ネイティブのバックアップと復元です。詳細については、「 Amazon S3 を使用したバックアップと復元 」を参照してください。 大規模なデータベースの復元は時間がかかるプロセスです。しかし、フル \ 差分 \ ログバックアップ戦略を使用することで、カットオーバー時間を短縮できます。さらに、バックアップ圧縮と複数のバックアップファイルを使用すれば、バックアップと復元のパフォーマンスが向上します ( 詳細は、 Amazon RDS for SQL Server のネイティブバックアップと復元のパフォーマンスの改善 を参照 )。復元パフォーマンスを改善するには、RDS DB インスタンスのネットワークと EBS の帯域幅使用状況を監視することが重要です。ボトルネックが発生した場合は、インスタンスサイズを拡張するか、追加のストレージ IOPS とスループットをプロビジョニングして、より速く復元を完了させることを検討してください。 Amazon RDS for SQL Server の Volume タイプを io2 Block Express に変更 Amazon RDS for SQL Serverでは、汎用 (gp2/gp3) とプロビジョンド IOPS (io1/io2) ボリュームを切り替えることができ、パフォーマンス要件の変化に合わせて柔軟に対応できます。ボリュームタイプを切り替えることで、アプリケーションの要求に応じてコストとパフォーマンスのバランスを取ることができます。 AWS マネジメントコンソール または AWS コマンドラインインターフェイス (AWS CLI) を使用して、RDS for Server インスタンスのストレージタイプを gp2、gp3、io1 から io2 Block Express に変更できます。 ただし、io2 ボリュームを使用する場合は、1 つ重要な点を考慮する必要があります。io2 ボリュームを使用し、ストレージサイズが 16 TiB を超える場合、gp2、gp3、または io1 に戻すことはできません。このシナリオで gp2、gp3、または io1 に戻すには、gp2、gp3、または io1 ボリュームを持つ新しいインスタンスを作成し、SQL Server のネイティブバックアップとリストアを使用してデータベースを移行する必要があります。既存の RDS for SQLServer インスタンスのボリュームタイプを変更する際の技術的な詳細と手順については、「 Amazon RDS DBインスタンスのストレージを使用する 」を参照してください。 大規模な io2 ボリュームを使用した自動バックアップの管理 最初の RDS DB スナップショットは、DB インスタンスのストレージボリュームの完全なバックアップを取得します。同じインスタンスでの後続のバックアップは増分 DB スナップショットになり、最新のバックアップ以降に変更されたデータのみを保存します。ほとんどの場合、DB インスタンスの日次バックアップは迅速に完了します。これは、日次バックアップが増分であるためです。ただし、自動バックアップが無効になっていて、大量の作業負荷があるか、数日間バックアップが行われていない特定の状況では、増分 DB スナップショットに蓄積されたデータのために、次のバックアップの完了に長時間を要する可能性があります。データ変更量が 64 TiB に達すると、バックアッププロセスには最大 4 日かかる可能性があります。この間、インスタンスは完全に機能し利用可能な状態が維持されますが、インスタンスタイプの変更やシングル AZ から マルチ AZ への変換などのインスタンスレベルの変更は制限されます。 大規模なデータベースの長時間実行される DB スナップショットのリスクを軽減するには、次の手順を実行できます。 RDS DB インスタンスの 自動バックアップ を常に有効にしておくことを検討してください。これにより、最後の DB スナップショットからデータの増分変更が長期間蓄積することがなくなります。 大規模な RDS DB インスタンスの日次自動バックアップスナップショットの完了には時間がかかる場合があります。そのため、バックアップ保持期間を少なくとも 7 日間に設定することをお勧めします。これにより、次のバックアップウィンドウを逃した場合でも、DB インスタンスのバックアップが利用可能になり、ポイントインタイムリカバリ (PITR) が可能になります。 マルチ AZ インスタンスの場合、1 〜 2 か月ごとに計画的な手動フェイルオーバーを実行することをお勧めします。この予防措置により、マルチデプロイメントの健全性が維持され、予期しないフェイルオーバー後に発生する可能性のある長いバックアップ時間を回避できます。予期しないフェイルオーバーが発生した場合に、新しいプライマリがキャッチアップする必要があり、長いバックアップ時間が発生するリスクを最小限に抑えます。定期的にフェイルオーバーを実行することで、プロセスが円滑かつ効率的であることが確認でき、フェイルオーバー戦略を検証し、高可用性設定に自信を持つことができます。 自動バックアップ時間と手動スナップショットを使用した PITR の最適化 大量のデータロード直後に手動でスナップショットを取ることで、次の自動バックアップが最後のスナップショット以降の変更のみをキャプチャするだけで済むようになります。この予防措置により、その後の自動バックアップに必要な時間が大幅に短縮されます。これは、バックアップする必要があるデータ量が最小限に抑えられるためです。全体のバックアップ時間を短縮することで、ピーク時の RDS インスタンスのパフォーマンスと可用性を維持することができます。手動スナップショットの作成手順の詳細については、「 シングル AZ DB インスタンスの DB スナップショットの作成 」を参照してください。 さらに、この方法により PITR (Point In Time Recovery) のパフォーマンスも向上することがわかっています。 PITR 機能を使用 すれば、SQL Server インスタンスを EBS io2 Block Express ボリュームに特定の時点まで復元することができます。 DBスナップショットからの復元 コンソール、AWS CLI、または Amazon RDS API を使用して DB スナップショットから RDS DB インスタンスを復元 できます。復元された DB インスタンスのステータスが使用可能になると、すぐに使用を開始できます。ただし、復元された DB インスタンスはバックグラウンドでデータの読み込みを続けます。このプロセスは遅延ロードと呼ばれます。 まだロードされていないデータにアクセスした場合、DB インスタンスは即座に Amazon S3 から要求されたデータをダウンロードし、その後バックグラウンドで残りのデータのロードを続行します。この遅延ロード処理中は、ボリュームが Amazon S3 から完全に再ハイドレートされるまで、レイテンシの上昇とパフォーマンスへの影響が発生する可能性があります。 遅延ロードとフルテーブルスキャン (SELECT *など) のような回避策の詳細については、「 DB スナップショットからの復元 」を参照してください。 大規模なボリュームでストレージを拡張するための計画的なメンテナンス時間枠を設定 ストレージ容量を拡張する必要がある場合は、既存の DB インスタンスのストレージを拡張できます。これは Amazon RDS コンソール、Amazon RDS API、または AWS CLI を使用して行うことができます。ただし、ストレージのスケーリング中に Amazon EBS がストレージの最適化を行う ため、ボリュームのサイズによっては長時間かかる可能性があります。そのため、ストレージのスケーリングは計画されたメンテナンスウィンドウ中に手動で実行し、自動ストレージスケーリング操作の頻度を最小限に抑えることをお勧めします。 Amazon RDS 上の SQL Server の大規模な読み取りレプリカの最適化 プライマリインスタンスの負荷状況によっては、 Amazon RDS の SQL Server のリードレプリカ の作成に時間がかかる場合があります。大量の作業負荷が予想される場合は、リードレプリカの作成前に手動でスナップショットを取得することをお勧めします。この予防措置により、リードレプリカの作成に必要な時間を最小限に抑えることができます。 シングル AZ DB インスタンスをマルチ AZ DB インスタンスに変換 io2 Block Express を使用している RDS for SQL Server インスタンスをシングル AZ から マルチ AZ に変換できます。シングル AZ インスタンスをマルチ AZ インスタンスに変換するのに必要な時間は、RDS DB インスタンスのプライマリノードの負荷によって異なります。大量の作業負荷が予想される場合は、作業負荷が完了した後に手動でスナップショットを取ることをお勧めします。これにより、マルチ AZ に変換する前に増分 DB スナップショットが最新の状態になり、変換時間が最小限に抑えられます。 結論 IOPS とストレージの比率の制限、および IOPS とスループットのスケーリング方法を理解することで、パフォーマンス要件に合わせて io2 Block Express ボリュームを使用した RDS for SQL Server インスタンスのサイズを適切に設定できます。 AWS Nitro System インスタンスは、最大 IOPS とスループットの能力が高くなっています。 SQL Server インスタンスで大規模な io2 ボリュームを使用する場合は、次のことをお勧めします。 自動バックアップを有効にしたままにしておき、移行中でも DB スナップショットが 20TiB を超えないようにしてください。 バックアップが数日かかる可能性があるため、バックアップ保持期間を最低 7 日に設定して、十分な DB スナップショット履歴が確保できるようにしてください。 大量の作業負荷の後に DB スナップショットを手動で取得し、自動の日次バックアップでキャプチャされるインクリメンタル DB スナップショットのサイズを最小限に抑えてください。 大量の作業負荷がある場合のマルチ AZ の構成では、計画外のフェイルオーバー後に非常に大きなスナップショットが発生するのを避けるため、1 〜 2 か月ごとにフェイルオーバーを実行してください。 DB スナップショットから復元した後は、他のボリュームタイプと同様に、アプリケーションスクリプトを実行して ハイドレーション (遅延ロード) を迅速化してください。 スケジューリングされたメンテナンスウィンドウ中に手動でストレージのスケーリングを行い、64TiB ボリュームの最適化には長い時間がかかるため、自動ストレージスケーリング操作の頻度を最小限に抑えてください。 これらの推奨事項に従うことで、EBS io2 Block Express ボリュームを使用して大容量の RDS for SQL Server インスタンスのパフォーマンス、バックアップ、メンテナンスを効果的に管理および最適化できます。本番環境で使用する前に、io2 Block Express ボリュームを使用した RDS for SQL Server DB インスタンス上の SQL Server ワークロードに対して、徹底的なパフォーマンステストとベンチマークを実施することを強くお勧めします。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Sudhir Amin は、Amazon Web Services のシニアソリューションアーキテクトです。ニューヨークを拠点に、さまざまな業界のお客様にアーキテクチャガイダンスと技術支援を提供し、クラウド導入を加速させています。彼はスヌーカーの大ファンで、ボクシングや UFC などの格闘技も好きです。また、世界で最も雄大な動物を間近で見られる、豊かな野生動物の生息地がある国々を旅行するのが大好きです。 Toby Xu は、Amazon Web Services の RDS チームでシニアプロダクトマネージャーを務めています。AWS に入社する前は、Oracle と Informatica でソリューションアーキテクトチームを率いていました。16 年以上にわたりデータベースとミドルウェア技術に携わってきた経験から、この分野に関する豊富な知識を有しており、ソフトウェアエンジニアリングの修士号を持っています。彼はクラウド技術に興味があり、革新的なソリューションを活用してお客様の目標達成を支援することに尽力しています。 Swarndeep Singh は、AWS のシニアソリューションアーキテクトです。彼は Amazon RDS チームで働き、商用データベースエンジンと SQL Server を専門としています。彼は　Amazon RDS での技術的課題に取り組むことを楽しみ、AWS のお客様と協力してカスタマイズされたソリューションを構築し、チームメイトと知識を共有することに注力しています。

はじめに 現在の経済環境では、コスト最適化が多くの企業の主要な優先事項となっています。企業が SAP を新規に導入、または最新バージョンに更新する際、SAP が実行される AWS サービスのコストを最適化できれば、その分のリソースを他のイノベーションに振り向けることができます。このブログでは、 SAP Lens for the AWS Well-Architected Framework のベストプラクティスを活用して、SAP ワークロードのコストと運用を最適化するためのインサイトと戦略を共有しています。 前提 開始する前に、目標を明確に設定し、総コストを算出し、 SAP on AWS 参考コストガイド を確認する必要があります。 SAP ワークロードが実行されているすべてのアカウントで、 AWS コストエクスプローラ を実行します。SAP で一般的に高コストとなるサービスは、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Elastic Block Store (Amazon EBS) 、 Amazon Simple Storage Service (Amazon S3) 、Amazon EBS スナップショット、 Amazon Elastic File Store (Amazon EFS) などです。本ブログではこれらのサービスの最適化とコスト削減のベストプラクティスと指針を示します。 Amazon EC2 Amazon EC2 から始めましょう。SAP ワークロードで Amazon EC2 インスタンスを選択する場合は、必ず SAP 認定 Amazon EC2 インスタンス 上で SAP NetWeaver と SAP HANA インスタンスを実行してください。 #1 ワークロードに最適なインスタンスサイズの選択 ワークロードに最適なインスタンスサイズの選択 とは、ワークロードのパフォーマンスと容量の要件を満たす最小限のコストのインスタンスタイプとサイズを選択するプロセスです。 Amazon EC2 インスタンスのサイズ変更は、ビジネスピークと四半期末期間を含めた過去 3 か月間の実際の使用状況に基づいて行う必要があります。そのためには、 Amazon CloudWatch と SAP Early Watch Alert を使用して使用状況分析を行います。 AWS Compute Optimizer の拡張インフラストラクチャメトリクス機能を有効にすると、Amazon CloudWatch のデータ 3 か月分を利用して推奨事項を生成できます。(デフォルトでは、AWS Compute Optimizer は Amazon CloudWatch のメトリクス履歴を最大 14 日間保存し、それを使って推奨事項を生成します。) 推奨事項の精度を上げるため、SAP EarlyWatch Alert レポートと比較してください。 分析に基づき、実行中のインスタンスを適切な SAP 認定 NetWeaver または HANA インスタンスに置き換えてください。 注 : Compute Optimizer は一般に信頼できますが、SAP ワークロードに対して最適でない推奨を行う場合がたまにあります。特にアイドルの SAP アプリケーションサーバーの場合に発生する可能性があります。これは、Compute Optimizer がワーク プロセスによって使用される予約済みメモリを考慮していないためです。そのため、Compute Optimizer の推奨を SAP 認定 インスタンスと照合して最適なパフォーマンスであることを確認することをお勧めします。 #2 SavingsPlans を活用する SavingsPlans は柔軟な価格モデルを提供し、1 年間または 3 年間の時間ベースの課金コミットメントと引き換えに、オンデマンド価格と比較して最大 72 % の料金削減が可能です。 オンデマンドで実行中の Amazon EC2 インスタンスが存在するかを確認し、ワークロードとインスタンスの使用状況が安定している場合は、 SavingsPlans に追加してください (例: 3 年間の前払い SavingsPlans を利用すれば、バージニア北部でオンデマンドの u-3tb1 Linux インスタンスよりも 60 % 以上安価になります)。 AWS Trusted Advisor と AWS Cost Explorer は、現在の SavingsPlans の利用状況と推奨事項を示します。 予測可能なワークロードのオンデマンドコストを避けるために、これを定期的 (月に 1 回程度) に見直す必要があります。 #3 Amazon EC2 インスタンスファミリの標準化でディスカウントを最大化 インスタンスファミリの標準化によって、利用率を最大化し、予約管理に関連する作業負荷を最小化します。 SAP で認定されている Amazon EC2 インスタンスファミリーとタイプは多数あります。コストを最適化するには、インスタンスファミリーとタイプを標準化する必要があります。例えば、小規模インスタンス (ASCS、SCS、WebDispatcher など) には Amazon EC2 C6i または最新世代を、SAP アプリケーションサーバーには Amazon EC2 M6i または最新世代を、1TB 未満の HANA データベースインスタンスには Amazon EC2 R6i または最新世代を使用してください。 #4 非本番用の Amazon EC2 インスタンスの開始 &amp; 停止を自動化する 開発環境、トレーニング環境、サンドボックス環境、プロジェクト関連のインスタンスは、稼働時間の要件が低い (1 日数時間のみ、または特定の日付のみ) 場合や、プロジェクトサイクルでの役割が短期間のみである可能性がありますので、これらのインスタンスに予約インスタンスを購入するのは費用対効果が低くなる恐れがあります。この場合、稼働時間の要件に基づいてコストを削減するために、 AWS Systems Manager または SAP Landscape Management を使用し、インスタンスの開始・停止をスケジューリングすることができます。 非本番の SAP ワークロード インスタンスの起動と停止を自動化することで、AWS コストを削減できます。 必要な時だけインスタンスを動作させれば、使われていないインスタンスに支払う必要がなくなります。 #5 最新世代の Amazon EC2 インスタンスへの移行 新しい世代のインスタンスタイプに移行することで、SAP ワークロードの価格性能を改善できます。 理由は、新しい世代のインスタンスでは SAPS が高く、価格が低いためです。 その結果、同等の性能を実現するために、インスタンスの台数やサイズを少なくできるかもしれません。 または、同じサイズの最新世代のインスタンスタイプに変更することで、ワークロードの増加に対応できます。 たとえば、m5 ファミリから m6i ファミリに移行すれば、インスタンスタイプ、OS、リージョンによっては、CPU が最大 15 % 高速、メモリ帯域幅が最大 20 % 高速、ネットワーク帯域幅が 25 ~ 100 % 高速になります。 #6 使用されていない オンデマンド キャパシティ予約 (ODCR) を解除する オンデマンド キャパシティ予約を利用すると、任意の期間、特定のアベイラビリティーゾーンで Amazon EC2 インスタンスのコンピューティングリソースを確保できます。 特定のインスタンスタイプを使った SavingsPlans で ODCR (オンデマンド キャパシティ予約)を作成した場合、Amazon EC2 インスタンスを利用できるようにするためです。インスタンスのサイズ変更、Amazon EC2 インスタンスファミリーの標準化、または別のインスタンスタイプへの移行後は、既存の ODCR をキャンセルし、適切なサイズのインスタンスの新しい ODCR を作成する必要があります。たとえば、u-3tb1.56xlarge から r6i.32xlarge にインスタンスを変更する場合、前の ODCR をキャンセルし、r6i.32xlarge の新しい ODCR を作成する必要があります。 未使用の ODCR を定期的にチェックするプロセスを実装してください。 #7 RTO と RPO に応じて、 AWS Elastic Disaster Recovery を使用して DR アーキテクチャを最適化 AWS Elastic Disaster Recovery (AWS DRS) を使用すれば、組織は新しい災害復旧プランを AWS に素早く簡単に実装したり、既存の災害復旧プランを AWS に移行することができます。 ソースシステムをステージングエリアのレプリケーションサーバーにレプリケーションすることで、低コストのストレージ、共有サーバー、最小限の計算リソースを使用することにより、継続したレプリケーションを維持しながら、災害復旧コストを最適化できます。 必要な RTO および RPO が達成できる場合は、AWS DRS ( SAP アプリケーションサーバーとデータベース に該当する場合) を、アクティブ・アクティブではなくディザスターリカバリー (DR) に活用してください。 RTO と RPO のオプションが異なる場合は、 SAP on AWS システムの復旧性 を管理するための他のデザインパターンを評価することを検討してください。 #8 クラウドの柔軟性を活かして、必要に応じて一時的なシステムを構築する AWS Launch Wizard は、SAP HANA などのサードパーティのアプリケーションに必要な AWS リソースをサイジング、構成、デプロイするための手順付きのウィザードです。 必要に応じて、AWS Launch Wizard を使って Amazon Machine Image (AMI) (サポートされている OS バージョン向けのセキュリティ強化プロセスで構築されたもの) から一時的なシステム (SAP HANA ベース) を構築し、そのシステムを稼働したままにしたり、シャットダウンするのではなく利用してください。インスタンスをシャットダウンしている場合でも、ストレージコストが発生するためです。 また、 AWS Service Catalog のプロダクト を AWS Launch Wizard で作成できます。 これにより、AWS Launch Wizard 内で事前に定義された SAP アーキテクチャを直接プロビジョニングできるため、チームは時間を節約できます。 Amazon EBS (Elastic Block Store) の概要 SAP HANA Tailored Data Center Integration (TDI) の要件を満たすには、EC2 インスタンスで SAP HANA を実行する際の最低限の構成として、必ず SAP HANA on AWS の 認定ストレージ構成 を使用してください。 これにより、最適なパフォーマンスを実現し、SAP のストレージ KPI を満たすことができます。 #1 最新の Amazon EBS ボリュームタイプを使用する GP2 から GP3 ボリュームタイプに Amazon EBS ボリュームを移行すると、コストを最大 20 % 節約できます。 #2 IO2 よりも Amazon EBS GP3 ボリュームタイプを使用する Amazon CloudWatch から Amazon EBS IO2 ボリュームの IOPS 使用量をチェックしてください。 IOPS の使用率が 16,000 を下回る場合は、ボリュームを IO2 から GP3 に移行することを検討してください。 また、16,000 IOPS の制限をバイパスし、より高い IOPS およびスループットを実現するために、 GP3 ボリュームのストライピング を検討することもできます。 注意: プロビジョンド IOPS SSD (IO2) ボリュームタイプは、サブミリ秒のレイテンシー、高い IOPS、スループット、高い耐久性 (99.999 %) が必要なミッションクリティカルなワークロードに使用してください。 #3 使用されていないAmazon EBSボリュームを削除してAWSのコストをコントロールする AWS コンソールで切り離された Amazon EBS ボリュームを確認し、今後使用する予定がない場合は削除してください。 切り離されたボリュームは、「終了時に削除」のフラグがない状態で起動された終了した Amazon EC2 インスタンスから残されている可能性があります。 #4 AWS Backup または AWS Backup Agent を使用して直接 AWS S3 ストレージにデータベースをバックアップする AWS Backup または AWS Backup Agent を使って、データベースのバックアップとリストアを直接 AWS S3 に対して行えます (anyDB と SAP HANA の高可用性環境の場合)。 こちら の手順に従って設定してください。 EC2 上の SAP HANA では、 AWS Backup * および AWS Backint Agent for SAP HANA が利用可能です。 Oracle on EC2: Oracle Secure Backup (OSB) モジュール を利用してください。 Symantec Advanced Solutions (Symantec 高度ソリューション) データベース: AWS File Gateway を使用して、データを非同期的に転送します。 これにより、(Amazon EFS または Amazon EBS のいずれかで) バックアップを保持するための一時保存用のストレージコストを避けることができます。 #5 データベース以外のボリュームの EBS スナップショットを最適化する Amazon EBS ボリュームや Amazon EC2 インスタンスを含む、さまざまな AWS リソースのバックアップ、リストア、およびポリシーベースの保持を行うための集中管理型サービスである AWS Backup を使用してください。 データベースサーバー: ルートボリュームとバイナリボリュームのスナップショットを有効にします データとログのボリュームのスナップショットを無効にしますが、データベースのバックアップ (データベースツールを使用) が適切に行われている必要があります アドホックのデータおよびログボリュームのスナップショットを AWS Backup と併用すれば、大規模データベースのシステムリフレッシュを迅速化できます SAP アプリケーションサーバー: ルートボリュームとバイナリボリューム (/usr/sap) のスナップショットを有効にします Amazon S3 #1 データベースのバックアップスケジュールと保持期間を改善する (AWS Backup Agent を使ってバックアップを S3 に取る場合) プロダクション、ステージング、プレプロダクション、品質管理、開発、サンドボックス、プロジェクト環境ごとに、フルバックアップとインクリメンタルバックアップを組み合わせたバックアップスケジュールを設定します。 このスケジュールは、各環境での復旧ニーズと、復旧に必要なデータの新しさ・タイムリーさを考慮し、適切な保持期間に基づくものにしてください。 たとえば、30 日のデータ保持期間がある開発環境やサンドボックス環境では、月次の完全バックアップと週次の増分バックアップで十分です。また、必要に応じて、これらの環境を本番環境やその他の環境のバックアップからリストアすることができます。 #2 Amazon S3 でライフサイクルポリシーを有効化する Amazon S3 分析 – ストレージクラス分析 を利用し、ストレージアクセスパターンを分析して、適切なデータを適切なストレージクラス(上記で特定の保持期間を設定したクラス)に移行するタイミングを判断します。 環境ごとのリカバリー要件とデータ保持期間に基づいて、ライフサイクルポリシーを設定してください。例えば、本番環境のバックアップは 5-7 日間は Amazon S3 Standard に格納し、その後、5 日以上前のバックアップの復元の必要性が非常に低い場合は、Amazon S3 Glacier または Amazon S3 Glacier Deep Archive で 6 か月保持するなど、低コストの格納先に移行します。 #3 バックアップのバージョン管理を無効にする バックアップのバージョン管理を無効にし、セキュリティのために マルチファクター認証による削除 または vault ロック を有効にします。 #4 DR リージョンに低コストストレージを採用 ビジネス継続および災害復旧 (BC/DR) のため Amazon S3 クロスリージョンレプリケーション (CRR) が有効な場合、復旧時間目標 (RTO) および復旧ポイント目標 (RPO) に応じて、災害復旧 (DR) リージョンに Amazon S3 Glacier や Amazon S3 Glacier Deep Archive などの低コストストレージを採用してください。 #4 インターフェイスまたはアーカイブファイルの保存には Amazon EBS や Amazon EFS ではなく、Amazon S3 を活用する ライフサイクルポリシーとバージョン管理を実装することで、インターフェイスまたはアーカイブファイルの保存に Amazon S3 を活用してコストを削減できます。 AWS SDK for SAP ABAP を使えば、SAP ABAP プログラムから Amazon S3 のファイルにアクセスできます。 #5 Amazon S3 の AWS Private Link AWS Private Link は、VPC (Virtual Private Cloud)、サポートされている AWS サービス、オンプレミスのネットワークの間でプライベート接続を提供し、トラフィックをパブリックインターネットに露出させません。 これは Amazon VPC エンドポイント を利用して実現されます。 Amazon EC2 と Amazon S3 間の接続を確立するための 接続先 を設定します。 これにより、データ転送に AWS バックボーンネットワークを使用し、インターネット出口料金を回避できます。 接続先はそれ自体と接続先がアクセスを提供するリソースのリソースポリシーで保護できます。 ゲートウェイエンドポイント を使用すると、VPC 用のインターネットゲートウェイや NAT デバイスを必要とせずに VPC から Amazon S3 にアクセスでき、追加料金はかかりません。 #6 Amazon S3 を定期的に、また大規模プロジェクト後に整理する SAP のインストールとアップグレードでは、データベース、カーネル、プロファイル、SUM ディレクトリ、SAP ソフトウェアファイルの一時的バックアップを保存するために多くの Amazon S3 ストレージ容量が必要になります。 ライフサイクルポリシーを有効にして保持期間を設定するか、プロジェクト完了後に Amazon S3 バケットを整理するタスクをプロジェクト計画に組み込んでください。 Amazon EFS の利用 Amazon EFS は、サーバー間で共有する必要があるファイルシステムである SAP の “/usr/sap/trans”、”/sapmnt”、その他のファイルシステムに利用できます。 https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html #1 未割り当ての Amazon EFS を確認する 未割り当ての Amazon EFS があれば、中身を確認したうえで削除してください。 #2 ライフサイクルポリシーを有効にする Amazon EFS ライフサイクル管理 を使用して、/usr/sap/trans、SARA がアクセスするアーカイブ、SOX 関連ファイル、SAP ソフトウェア、SAP のインストールとアップグレードツール、バックアップなどの SAP のファイルストレージの経済的な管理を行うことができます。 Amazon EFS の Intelligent Tiering は、ワークロードのファイルアクセス状況を監視し、ファイルシステムの Infrequent Access (IA) ストレージクラスへのファイルを自動的に移行させるように設計されています。 #3 Amazon EFS を定期的にクリーンアップし、大規模なプロジェクトが完了した後にも行う SAP のインストールやアップグレードには、SAP ソフトウェアファイルや Software Provisioning Manager、Software Update manager などの SAP ツールを保存するために大量の Amazon EFS ストレージが必要になります。 結論 SAP と AWS のベストプラクティスに従って、SAP ワークロードのコストを最適化することは不可欠ですが、顧客にとっては難しい課題となります。 AWS Trusted Advisor や AWS Cost Explorer などの AWS サービスを利用すれば、SAP ワークロードのコストを分析・モニタリングしたり、Amazon S3 や Amazon EFS のライフサイクルポリシーや、SAP 向けに認定されたインスタンス種別やストレージ種別を確認したりできます。これらは、コスト最適化に重要となる分野です。 AWS コスト配分タグ を活用すれば、AWS のコストを細かいレベルで追跡して高額となる要因を特定することができます。 予算超過を防ぐ ためのプロセスとガバナンスを整備してください。 次のステップ 毎四半期 (または必要に応じて) 、 SAP Lens レビュー を AWS Well-Architected ツール (AWS WA ツール) で自助型のコスト最適化の観点から実施してください。AWS WA ツールの実行では、AWS テクニカルアカウントマネージャー (TAM) またはアカウントチームに支援を求めてください。 クラウドリソース管理サービス を実装し、コスト最適化を継続的に監視および改善してください。 ご質問やご確認事項がある場合は、AWS サポートまでお問い合わせください。また、分析中は AWS テクニカルアカウントマネージャー (TAM) または AWS ソリューションアーキテクトにご相談ください。 翻訳は Partner SA 松本が担当しました。原文は こちら です。