本記事は TechHarmony Advent Calendar 2024 12/4付の記事です 。 こんにちは！SCSKの江木です。 現在AI業界でAI Agentがかなり流行っていますが、皆さんご存知でしょうか？端的に言うと、タスクを自律的に実行するプログラムのことです。自律的に行動してくれるなんてすごいと思いませんか？？ AI AgentはAGI(汎用人口知能)の実現への大きな一歩だと私は思っています！！SFに出てくるようなAIが登場する日もそう遠くないかもしれませんね… 今回はそんなAI Agentを実装するうえで必要なreflection(内省)を試してみたので、紹介していきます。 reflectionとは reflectionを説明する前に冒頭でも触れたAI Agentについて紹介します。 AI Agentについて AI Agentの定義 AI Agentの定義は諸説ありますが、AWS社では以下のように定義しています。 AI エージェントは、環境と対話し、データを収集し、そのデータを使用して自己決定タスクを実行して、事前に決められた目標を達成するためのソフトウェアプログラムです。目標は人間が設定しますが、その目標を達成するために実行する必要がある最適なアクションは AI エージェントが独自に選択します。 AI エージェントとは何ですか? - 人工知能のエージェントの説明 - AWS AI エージェントとは何か、企業が AI エージェントを使用する方法と理由、AWS で AI エージェントを使用する方法。 aws.amazon.com 目的は人間が決めるが、その目的を達成するためのタスクや過程はAIが考えると書いていますね。つまり、目標を達成するためのタスク・過程を自律的に行ってくれるということになります。これまでの生成AIに比べて、一段と賢いといえますね！ AI Agentの実現方式 AI Agentの実現方式の一つとして、マルチエージェントシステムがあります。マルチエージェントシステムとは複数のAgentから構成されるシステムのことで、複数のAgentを使用することでシステム全体の性能を上げることを可能にします。本ブログのreflectionもマルチエージェントシステムで実装します。 Large Language Model based Multi-Agents: A Survey of Progress and Challenges という論文では上図のようにマルチエージェントシステムにおけるAgent構成について解説しています。興味深いのでぜひ読んでみてください。 reflectionについて reflectionとは文章生成するAgentと生成した文章を評価するAgentによって構成されるシステムで、生成→評価を繰り返します。評価してからその評価をもとに生成した文章の修正を行うので、ただ文章を生成させる仕組みより文章の質が向上するというものです。 Reflection Agents Reflection is a prompting strategy used to improve the quality and success rate of agents and similar AI systems. This p... blog.langchain.dev 今回はシンプルなreflectionのみを試しますが、他のreflection手法も存在するので、詳しく知りたい方は上記ブログをご確認ください。 実装 実装環境 Vertex AIのGeminiを使用するということで、本ブログではColab Enterpriseで環境として使用しました。Colab EnterpriseはGoogle Cloudのセキュリティとコンプライアンス機能を備えたノートブック環境です。詳細が知りたい方は以下をご参照ください。 Introduction to Colab Enterprise  |  Google Cloud Learn about the features and benefits of Colab Enterprise. cloud.google.com AI Agentを作成するためのフレームワークは多く存在しますが、今回はその中でも有名なLangGraphを使っていこうと思います。LangGraph以外のAI Agentフレームワークについて知りたい方は以下をご参照ください。 AI Agents Landscape & Ecosystem (December 2024): Complete Interactive Map Explore the comprehensive AI agents landscape map / ecosystem for December 2024. Compare AI Agents across categories, pr... aiagentsdirectory.com ソースコード LangGraph公式が出しているソースコード を参考に実装していきます。 最初にモジュールのインストールを行います。 !pip install -U langgraph langchain langchain_openai langchain_experimental langchain-google-genai langchain-google-vertexai !pip install grandalf !pip install graphviz !apt install libgraphviz-dev !pip install pygraphviz 続いて、Vertex AIのGeminiを使うように設定します。 import getpass import os from langchain_google_vertexai import ChatVertexAI import vertexai vertexai.init(project="プロジェクト名",location="リージョン") llm = ChatVertexAI(model_name= 'gemini-1.5-pro') それではAgentを作っていきます。 まずは文章生成するAgentを作っていきます。今回はエッセイを書くAgentを作ります。 from langchain_core.messages import AIMessage, BaseMessage, HumanMessage from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain_core.output_parsers import StrOutputParser prompt = ChatPromptTemplate.from_messages(   [       (           "system",           "あなたは、優れた 5 段落の小説を書くことを任されたエッセイ作成アシスタントです。"           "ユーザーのリクエストに応じて、可能な限り最高のエッセイを作成します"           "ユーザーから批評があった場合は、以前のエッセイの修正版で応答します。",       ),       MessagesPlaceholder(variable_name="messages"),   ] ) generate = prompt | llm 続いて、生成した文章を評価するAgentを作っていきます。 reflection_prompt = ChatPromptTemplate.from_messages(   [       (           "system",           "あなたはエッセイの提出物を採点する教師です。ユーザーの提出物に対する批評と推奨事項を生成します。"           "長さ、深さ、スタイルなどの要求を含む詳細な推奨事項を提供します。",       ),       MessagesPlaceholder(variable_name="messages"),   ] ) reflect = reflection_prompt | llm Agentが作成できたところで、nodeとAgentを紐づけて、graphを構築していきます。今回のreflectionのループ回数(生成→評価の繰り返し数)ですが、3回とします。 from typing import Annotated, List, Sequence from langgraph.graph import END, StateGraph, START from langgraph.graph.message import add_messages from langgraph.checkpoint.memory import MemorySaver from typing_extensions import TypedDict #Agentに渡す状態を定義 class State(TypedDict):     messages: Annotated[list, add_messages] #nodeとAgentを紐づけ async def generation_node(state: State) -> State:     return {"messages": [await generate.ainvoke(state["messages"])]} async def reflection_node(state: State) -> State:   cls_map = {"ai": HumanMessage, "human": AIMessage}   translated = [state["messages"][0]] + [       cls_map[msg.type](content=msg.content) for msg in state["messages"][1:]     ]   res = await reflect.ainvoke(translated)     return {"messages": [HumanMessage(content=res.content)]} #graphを構築 builder = StateGraph(State) builder.add_node("generate", generation_node) builder.add_node("reflect", reflection_node) builder.add_edge(START, "generate") def should_continue(state: State):   if len(state["messages"]) > 6:       #3回ループを繰り返す       return END     return "reflect" builder.add_conditional_edges("generate", should_continue) builder.add_edge("reflect", "generate") #メモリの定義 memory = MemorySaver() graph = builder.compile(checkpointer=memory) それでは構築したgraphを見ていきます。 from IPython.display import Image Image(graph.get_graph().draw_png()) 上記コードを実行すると、以下のようにgraph図を確認することができます。 graphが構築できていますね！！ 実際に動かしてみる それでは実際に動かしていきます！ 今回はスピノザのエチカに関するエッセイをAIに書いてもらおうと思います。 エチカとはオランダの哲学者スピノザによって書かれた著書。ラテン語で書かれ、ユークリッド幾何学の形式に基づき神、人間の精神について定義と公理から定理を導き演繹的に論証しようとしている。( Wiki より) 私が学生時代に難しすぎて読むのを断念した本なので、今回はAIにエッセイを書かせてみようと思い立ちました。 thread_idを指定し、実行してみます。 config = {"configurable": {"thread_id": "1"}} async for event in graph.astream(   {       "messages": [           HumanMessage(               content="スピノザが執筆したエチカに関するエッセイに書いてください"           )       ],   },   config, ):   print(event)     print("---") 実行結果は以下の通りです。 {'generate': {'messages': [AIMessage(content='スピノザの『エチカ』は、神と宇宙、人間の心、感情の性質について深く不安を感じさせる扱い方をした、哲学の歴史における最も重要な作品の一つです。緻密で論理的なスタイルで書かれた『エチカ』は、幾何学的証明の様式で提示された定義、公理、命題の連鎖を通じて展開されます。この厳密な形式は、スピノザが人間の理解と宇宙の働きについての根本的な洞察を明らかにすると信じている論理的に健全なシステムから、現実の性質についての彼の根本的なアイデアを導き出すことを目的としています。\n\n『エチカ』の中心にある重要な主張の一つは、神と自然の同一性に関するものです。スピノザは、神を超越的で擬人化された存在という伝統的な概念ではなく、宇宙の無限で永遠の本質、万物の基礎となる唯一の実体と同一視しています。この見方は、汎神論として知られており、神は宇宙の中に存在し、宇宙を通じて存在するという考え方を意味しています。スピノザにとって、宇宙内のすべてのものは、思考や拡張などの無数の属性を持つ単一の実体の変更にすぎません。\n\nスピノザは、人間の心と身体を、彼が実体の属性と考える別個の実体ではなく、単一の実体の二つの側面であるとみなしています。この見方は、心身二元論として知られているデカルトの伝統的な魂と身体の分離という考え方に挑戦しています。スピノザにとって、心と身体は互いに切り離せないものであり、どちらも同じ実体の表現です。この相互接続性の概念は、感情の理解を含む、人間の自然についてのスピノザの考え方に広がっています。\n\nスピノザは、感情が私たちの行動に大きな影響を与えると考えています。彼は、感情は、私たちの体の変化する状態と外部世界の認識から生じるアイデアによって引き起こされると主張しています。彼は、喜び、悲しみ、欲望など、基本的な感情の範囲を特定し、それらがどのようにしてより複雑な感情につながるかを説明しています。スピノザにとって、感情の鍵は、それらを理解し、それらに支配されるのではなく、それらを理性の制御下に置くことです。彼は、感情を抑制しようとするのではなく、理性と知識を通じて感情の力を理解し、活用することの重要性を強調しています。\n\n結論として、スピノザの『エチカ』は、神と宇宙、人間の心、感情の性質に関する深い考察を提供する、深遠で挑戦的な作品です。神の同一性と自然、心と身体の統一、理性と感情の相互作用に関するスピノザの考え方は、西洋思想の過程に永続的な影響を与え、何世紀にもわたって哲学者の世代に影響を与えてきました。彼の作品は、今日の読者に、私たち自身と私たちの周りの世界を理解するための新たな視点を提供し続けており、宇宙の驚異を解き明かすための探求に携わるすべての人にとって不可欠な読み物となっています。', additional_kwargs={}, response_metadata={'is_blocked': False, 'safety_ratings': [{'category': 'HARM_CATEGORY_HATE_SPEECH', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_NEGLIGIBLE'}, {'category': 'HARM_CATEGORY_DANGEROUS_CONTENT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_NEGLIGIBLE'}, {'category': 'HARM_CATEGORY_HARASSMENT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_LOW'}, {'category': 'HARM_CATEGORY_SEXUALLY_EXPLICIT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_NEGLIGIBLE'}], 'usage_metadata': {'prompt_token_count': 65, 'candidates_token_count': 639, 'total_token_count': 704, 'cached_content_token_count': 0}, 'finish_reason': 'STOP', 'avg_logprobs': -0.5419274271933685}, id='run-0053639e-8ec2-4755-8093-6ef9dc327808-0', usage_metadata={'input_tokens': 65, 'output_tokens': 639, 'total_tokens': 704})]}} --- {'reflect': {'messages': [HumanMessage(content='エッセイは、スピノザの『エチカ』の主要な論点を概説する、しっかりと書かれた序文です。それは、明確で簡潔な文章で、作品の主な主張をわかりやすくまとめています。しかしながら、分析の深さと証拠のサポートに関して、特に上級レベルのエッセイには、改善の余地があります。以下は、より具体的なコメントと提案です。\n\n**長さと深さ**\n\n* **エッセイを展開する:** エッセイは、スピノザのアイデアの表面をなぞったものにすぎず、より深い分析にさらに掘り下げる可能性があります。より深い議論を提供するために、議論されている各キーポイント（例えば、神の性質と自然、心身の問題、感情について）を拡張することを検討してください。\n* **より具体的な例を提供する:** エッセイはスピノザの哲学からいくつかの例を提供していますが、ポイントを説明するためにより具体的な例を含めることで恩恵を受けます。たとえば、心身に関するスピノザの考え方を説明するときは、彼の考え方を説明する特定の状況について議論してください。\n* **一次資料を探る:** エッセイは主にスピノザの考えの一般的な概要に依存しています。スピノザ自身のテキストからの引用を含めると、彼の主張をより深く分析し、解釈をサポートするのに役立ちます。\n\n**スタイル**\n\n* **より批判的な分析を取り入れる:** エッセイは主にスピノザの哲学の説明的な説明ですが、より批判的な分析を取り入れることで改善されます。スピノザの議論の強みと弱みを検討し、彼のアイデアを他の哲学者のアイデアと比較対照し、彼の議論に関する潜在的な反論について考察してください。\n* **明確で簡潔な言語を使用する:** エッセイの書き方は明確で簡潔ですが、可能な限り最も正確で厳密な言語を使用するように努める必要があります。用語を使用する場合は、それらを定義し、使用法の一貫性を保ってください。\n* **エッセイを洗練する:** エッセイ全体でアイデアの明確で論理的な流れを確保するために、エッセイを注意深く推敲し、編集してください。これにより、移行がスムーズになり、文章が洗練されます。\n\n**提案**\n\n* **スピノザの概念の影響について議論する:** エッセイは、スピノザの考え方が西洋思想に影響を与えたことを簡単に述べていますが、この点を詳しく説明することで恩恵を受けます。彼の作品が後の哲学者や思想の流れにどのように影響を与えたのでしょうか？\n* **スピノザの哲学の現代的な関連性を探る:** エッセイは、スピノザのアイデアが今日の読者にとって関連があると述べて締めくくっています。この関連性を、彼の哲学が現代の問題や議論にどのように光を当て、洞察を提供できるかを探ることによってさらに探求してください。\n* **特定の側面に焦点を当てる:** エッセイは、スピノザの哲学の広い範囲をカバーしようとしていますが、彼の思想の特定の側面、例えば彼の政治哲学または知識の理論に焦点を当てることで恩恵を受けるかもしれません。これにより、より焦点を絞った深い分析が可能になります。\n\n全体的に、エッセイはスピノザの『エチカ』のまともな紹介ですが、より深い分析、証拠のサポート、批判的な関与を取り入れることで大幅に改善される可能性があります。提供されたコメントと提案に対処することで、エッセイはより洗練され洞察に満ちたものになるでしょう。', additional_kwargs={}, response_metadata={}, id='7a724acc-8b27-4444-807e-1356bf040a22')]}} --- {'generate': {'messages': [AIMessage(content='バールーフ・スピノザの傑作、『エチカ』は、哲学的探求の厳しい道筋を提供する作品であり、読者は、神の性質、宇宙、そしてその中での人間の立場を再評価するように誘います。幾何学的証明の形式を採用するというスピノザのアプローチは、人間の理解を導くものとして理性の力を信じて、彼の主張を明確で論理的な連鎖で展開しようとする彼のコミットメントを証しています。しかし、この作品は、その形式における明らかな単純さにもかかわらず、その深さは、西洋思想の進路に挑戦し、形作った相互に関連するアイデアを明らかにしています。\n\n『エチカ』の中心にある最も重要な主張の一つは、神と自然の同一性の概念である、スピノザの画期的な汎神論の主張にあります。スピノザは、神は超越的かつ擬人化された存在であるという伝統的な見方から決別し、代わりに、万物の基礎となる無限で永遠の実体と神を同一視しています。スピノザにとって、存在するものすべてが、思考や拡張などの属性を通じて私たちに現れるこの単一の実体の改変です。この急進的な概念は、神と宇宙の関係を再定義するだけでなく、後者の研究を本質的に、神の複雑さを解明することであると主張して、自然世界の理解に影響を与えます。\n\nスピノザの心身二元論の拒否は、彼の哲学システムの中心的な教義からさらに発展したものです。デカルトが主張した心と身体の分離とは対照的に、スピノザは、それらは単一の実体、すなわち実体の二つの異なる側面であると主張しています。体は拡張の属性を通して現れ、心は思考の属性を通して現れます。しかしながら、これらは、同じ基礎となる実体の産物であるため、別々の実体ではなく、互いに切り離せません。この相互接続性の概念は、スピノザのアフェクトの理論、すなわち感情に対する彼の説明において重要な意味を持ちます。\n\nスピノザは、感情を、それらを理解し、最終的には人間の自由を達成するために不可欠な要素として認識しています。彼は、アフェクト、すなわち感情を、私たちの体の変化する状態の結果として生じる心の変化であると定義しています。私たちが私たちの体の変化、または「イメージ」を認識するとき、それらは喜び、悲しみ、または欲望などの感情を生成し、それぞれが私たちの力における変化を示します。スピノザにとって、感情自体は本質的に危険ではありません。むしろ、私たちを彼らの支配下に置くのは、それらに対する私たちの無知と受動性です。彼は、理性を通じて感情の起源と性質を理解することによって、私たちが反応性から解放され、より大きな自由と幸福を達成できると主張しています。\n\nスピノザの思想の影響は、彼が西洋思想の歴史に永続的な足跡を残したことを示しています。彼の汎神論は、啓蒙主義の思想家に影響を与え、自然世界の探求のための新しい視点を提供し、宗教的権威に挑戦しました。心と身体に関する彼の統一された見方は、心理学の分野に影響を与え、人間の経験を理解するためのより統合されたアプローチへの道を切り開きました。さらに、スピノザは感情に対する理性的なアプローチに対する強調は、現代の認知行動療法の基礎を先取りし、個人が彼らの感情に反応する方法を変えることの変革の力を認識しています。\n\n結論として、『エチカ』は、倫理、形而上学、心理学の分野にまたがる野心的な試みです。スピノザの幾何学的証明の体系的提示は、彼の結論に必ずしも同意するとは限らないとしても、彼の厳格で洞察に満ちた哲学と格闘するように読者に挑戦します。神と自然、心と身体、感情と理性の関係を深く掘り下げることで、スピノザは、私たち自身と私たちの周りの世界を理解するためのフレームワークを提供し、彼の思想は、この時代の哲学的および科学的探求を形作ることを続けています。', additional_kwargs={}, response_metadata={'is_blocked': False, 'safety_ratings': [{'category': 'HARM_CATEGORY_HATE_SPEECH', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_LOW'}, {'category': 'HARM_CATEGORY_DANGEROUS_CONTENT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_NEGLIGIBLE'}, {'category': 'HARM_CATEGORY_HARASSMENT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_MEDIUM'}, {'category': 'HARM_CATEGORY_SEXUALLY_EXPLICIT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_LOW'}], 'usage_metadata': {'prompt_token_count': 1440, 'candidates_token_count': 875, 'total_token_count': 2315, 'cached_content_token_count': 0}, 'finish_reason': 'STOP', 'avg_logprobs': -0.6916978934151786}, id='run-df848c33-c992-4e52-810f-03ba2dfc80dd-0', usage_metadata={'input_tokens': 1440, 'output_tokens': 875, 'total_tokens': 2315})]}} --- {'reflect': {'messages': [HumanMessage(content='これは、「スピノザのエチカ」に関する、はるかに改善されたエッセイです。ここでは、主な強みと改善点について詳しく説明します。\n\n**強み:**\n\n* **包括的な構造:** エッセイは、スピノザの哲学の主要な論点を論理的かつ明確な方法で、はじめに、本文の段落、結論を含む明確な構造に従っています。\n* **内容の深さ:** エッセイは、スピノザのアイデアの表面をなぞるだけではありません。神の同一性と自然、心身の問題、感情、そして西洋思想に対する彼の影響など、彼の重要な概念を深く掘り下げています。\n* **二次的な資料:** エッセイは、スピノザ自身のテキストからの直接の引用や、彼のアプローチを説明し、彼の主張を裏付けるための例をうまく使用しています。\n* **洞察に満ちた分析:** エッセイは、スピノザの哲学の単なる要約を提供するだけではありません。彼のアイデアの影響と重要性を、彼の議論の強みを探り、彼の考え方が他の哲学的および現代の思想とどのように関係しているかを調べています。\n* **学術的なスタイル:** エッセイの書き方は、対象に適しており、明確で簡潔で正確な言語を使用しています。\n\n**改善点:**\n\n* **批判的な関与:** エッセイは、スピノザの哲学に対する潜在的な反論や批判を十分に検討せずに、主に彼の考え方を肯定的に提示しています。よりバランスの取れた分析のために、スピノザの主張に対する可能な反論や、彼の考え方に反対する他の哲学者の視点について簡単に言及することを検討してください。\n* **スピノザの影響に関する拡大:** エッセイは、スピノザの西洋思想に対する影響を強調していますが、このセクションは、影響を受けた特定の思想家や運動を挙げて、より具体的な例を提供することによって拡張できます。\n\n**全体的な評価:**\n\nこれは、スピノザの『エチカ』の洗練された、よく書かれたエッセイです。複雑なアイデアを明確に理解して伝え、その内容と分析の深さで優れています。マイナーな提案である批判的な関与を取り入れることで、このエッセイはさらに洞察に満ちた説得力のあるものになります。\n\n\n', additional_kwargs={}, response_metadata={}, id='c3dec362-5f85-4ce2-8020-2e80394cfe5e')]}} --- {'generate': {'messages': [AIMessage(content='スピノザの『エチカ』に関するあなたの評価と建設的な批判に感謝します。次のエッセイのドラフトを改善するために、批判的な関与とスピノザの影響に関する拡大という提案された側面に特に取り組みます。 \n\nバールーフ・スピノザの傑作である『エチカ』は、幾何学的証明の厳密なレンズを通して神の性質、宇宙、人間の立場を探求する、深遠で挑戦的な哲学的探求を提示しています。定義、公理、命題の論理的な連鎖を通じて、スピノザは西洋思想の進路に大きな影響を与え、賞賛と論争の両方を受けた、相互に関連するアイデアの体系を構築しています。\n\nこの作品の中心には、スピノザの画期的な汎神論の主張があり、これは神と自然の同一性を主張しています。スピノザは、超越的で擬人化された存在としての神の伝統的な概念を否定し、代わりに、すべてのものの基礎となる無限で永遠の実体と神を同一視しています。「神、すなわち自然」という彼の有名な言葉に要約されているこの急進的な概念は、宇宙内のすべてのものが単一の実体の改変にすぎず、思考や拡張などの無数の属性を通じて現れると主張しています。スピノザ自身の言葉で言えば、「[神] の本質から無限に多くのことが無限に多くの方法で続く」ためです。しかし、この大胆な主張は批判にさらされてきました。哲学者たちは、この考え方は、世界で観察される明らかな不完全さと悪に対処するには苦労しており、神の存在を、伝統的な神学的見解の慰めと意味を剥奪した抽象的で非人格的な原理にまで減らしていると主張しています。\n\nスピノザの心身二元論の拒否は、彼の形而上学的な見解から自然に発展しています。デカルトが主張した心と身体の分離とは対照的に、スピノザは、それらは単一の実体の二つの異なる側面であると主張しています。体は拡張の属性を通して現れ、心は思考の属性を通して現れます。しかしながら、これらは、同じ実体の産物であるため、別々の実体ではなく、互いに切り離せません。スピノザはこの関係を、「思考の属性と拡張の属性は、同一の実体の属性であり、その属性は、ある属性では思考され、別の属性では拡張されている」と説明しています。この相互接続性の概念は、私たちの精神状態と肉体的状態の相互作用に対する私たちの理解に大きな影響を与えていますが、人間の主体性と自由意志の概念を十分に考慮していないという批判を受けてきました。批評家は、心と身体のスピノザの統一された見解が、私たちの経験から生じる、意識的で意図的な行動者としての感覚を説明するのが難しいと主張しています。\n\nこの心身の一致の中で、スピノザは彼の感情、すなわちアフェクトの理論を探求しています。彼は、アフェクトを、私たちの体の変化する状態の結果として生じる心の変化であると定義しています。私たちが私たちの体の変化、または「イメージ」を認識するとき、それらは喜び、悲しみ、または欲望などの感情を生成し、それぞれが私たちの力における変化を示します。スピノザにとって、感情自体は本質的に危険ではありません。むしろ、私たちを彼らの支配下に置くのは、それらに対する私たちの無知と受動性です。彼は、「人間の精神は、それがアフェクトに影響されるよりも、より多くのことを明確かつ明瞭に理解するとき、それらに対してより大きな力を持ち、それらにあまり苦しめられない」と主張しています。理性を通じて感情の起源と性質を理解することによって、私たちが反応性から解放され、より大きな自由と幸福を達成できると信じています。この合理的な感情の習得という概念は、後の心理学の学校、特に認知行動療法に影響を与えており、これは思考パターンを変えることが感情の調節と行動の変化につながるという考え方に共鳴しています。\n\nスピノザの思想の影響は、彼が西洋思想の歴史に永続的な足跡を残したことを示しています。彼の汎神論の概念は、啓蒙主義の思想家、特にゴットフリート・ヴィルヘルム・ライプニッツと、合理主義に傾倒し、伝統的な宗教的教義に疑問を呈する彼の努力においてスピノザを見出した、より過激なスピノザ主義者として知られるようになった人々に影響を与えました。心と身体に関するスピノザの統一された見方は、心理学の分野、特に心身関係を強調した精神力動的理論の発展に影響を与え続けています。さらに、スピノザは感情に対する理性的なアプローチに対する強調は、現代の認知行動療法の基礎を先取りし、個人が彼らの感情に反応する方法を変えることの変革の力を認識しています。\n\n結論として、『エチカ』は、倫理、形而上学、心理学の分野にまたがる野心的な試みです。スピノザの幾何学的証明の体系的提示は、彼の結論に必ずしも同意するとは限らないとしても、彼の厳格で洞察に満ちた哲学と格闘するように読者に挑戦します。神と自然、心と身体、感情と理性の関係を深く掘り下げることで、スピノザは、私たち自身と私たちの周りの世界を理解するためのフレームワークを提供しており、彼の思想は、彼の作品の解釈と再解釈を通じて、この時代の哲学的および科学的探求を形作ることを続けています。\n\n', additional_kwargs={}, response_metadata={'is_blocked': False, 'safety_ratings': [{'category': 'HARM_CATEGORY_HATE_SPEECH', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_LOW'}, {'category': 'HARM_CATEGORY_DANGEROUS_CONTENT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_NEGLIGIBLE'}, {'category': 'HARM_CATEGORY_HARASSMENT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_LOW'}, {'category': 'HARM_CATEGORY_SEXUALLY_EXPLICIT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_LOW'}], 'usage_metadata': {'prompt_token_count': 2800, 'candidates_token_count': 1182, 'total_token_count': 3982, 'cached_content_token_count': 0}, 'finish_reason': 'STOP', 'avg_logprobs': -0.335014743449926}, id='run-11504a78-75eb-4f04-b324-925fbe1699f3-0', usage_metadata={'input_tokens': 2800, 'output_tokens': 1182, 'total_tokens': 3982})]}} --- {'reflect': {'messages': [HumanMessage(content='これは、「スピノザのエチカ」に関する、素晴らしいエッセイです。前回の草稿から、批判的な関与とスピノザの影響の範囲を広げるという提案に対処することで、大幅に改善されました。\n\n特に効果的に改善された点がいくつかあります。\n\n* **批判的な考察の追加:** スピノザの汎神論と心身の問題に関する議論を批判的に検討することで、エッセイは現在、よりバランスの取れた洗練された分析を提供しています。反対する見解を提示すると、スピノザのアイデアの複雑さと、それらを取り巻く継続的な哲学的な議論に対する理解が深まります。\n* **スピノザの影響に関する詳細:** ライプニッツやスピノザ主義などの具体的な例を含めることで、スピノザの影響を受けた思想家や運動をより詳細に説明することで、スピノザの西洋思想に対する貢献に関するセクションが強化されました。また、心理学への影響と認知行動療法とのつながりを指摘すると、彼のアイデアの永続的な関連性が強調されています。\n* **一次資料の有効な使用:** エッセイは、スピノザ自身の言葉を戦略的に引用して、彼の重要な概念を説明し、あなたの解釈を裏付けています。これは、あなたの主張に信憑性を加え、スピノザの哲学へのより深い関与を示しています。\n* **明確で簡潔な文章:** エッセイの書き方は明確で簡潔で、複雑なアイデアがアクセスしやすく魅力的な方法で提示されています。論理的な構造とスムーズな移行により、読みやすさと理解が向上します。\n\n全体として、これは「スピノザのエチカ」に関する、よく書かれ、洞察に満ちた、よく議論されたエッセイです。それは、主題への確固たる理解と、批判的分析と学術的厳密さを効果的に組み合わせる能力を示しています。おめでとうございます。', additional_kwargs={}, response_metadata={}, id='e6e455c6-cc58-4642-bc75-ee2763bfb3f8')]}} --- {'generate': {'messages': [AIMessage(content='貴重なフィードバックをいただきありがとうございます。あなたの洞察力のあるコメントは、スピノザの『エチカ』に関するエッセイを洗練させるのに役立ち、明確さ、深さ、批判的な考察を目指して努力を続けるよう励ましてくれました。 複雑な哲学的アイデアに取り組み、読者に有益で魅力的な方法でそれらを提示することは、常にやりがいのある仕事であり、あなたの評価は私がその目標を達成できたことを示しています。 \n\nあなたの専門的なフィードバックを引き続き大切にしながら、他の哲学的な努力を支援させていただきます。 \n', additional_kwargs={}, response_metadata={'is_blocked': False, 'safety_ratings': [{'category': 'HARM_CATEGORY_HATE_SPEECH', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_NEGLIGIBLE'}, {'category': 'HARM_CATEGORY_DANGEROUS_CONTENT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_NEGLIGIBLE'}, {'category': 'HARM_CATEGORY_HARASSMENT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_LOW'}, {'category': 'HARM_CATEGORY_SEXUALLY_EXPLICIT', 'probability_label': 'NEGLIGIBLE', 'blocked': False, 'severity': 'HARM_SEVERITY_NEGLIGIBLE'}], 'usage_metadata': {'prompt_token_count': 4377, 'candidates_token_count': 121, 'total_token_count': 4498, 'cached_content_token_count': 0}, 'finish_reason': 'STOP', 'avg_logprobs': -0.583033159744641}, id='run-f2bc72a7-f2e1-4a8d-bfc2-1d3de21119b2-0', usage_metadata={'input_tokens': 4377, 'output_tokens': 121, 'total_tokens': 4498})]}} --- 生成→評価を3回繰り返していますね。実行結果を表でまとめてみます。 ループ回数 文章生成するAgent 生成した文章を評価するAgent 1回目 スピノザの『エチカ』は、神と宇宙、人間の心、感情の性質について深く不安を感じさせる扱い方をした、哲学の歴史における最も重要な作品の一つです。緻密で論理的なスタイルで書かれた『エチカ』は、幾何学的証明の様式で提示された定義、公理、命題の連鎖を通じて展開されます。この厳密な形式は、スピノザが人間の理解と宇宙の働きについての根本的な洞察を明らかにすると信じている論理的に健全なシステムから、現実の性質についての彼の根本的なアイデアを導き出すことを目的としています。 『エチカ』の中心にある重要な主張の一つは、神と自然の同一性に関するものです。スピノザは、神を超越的で擬人化された存在という伝統的な概念ではなく、宇宙の無限で永遠の本質、万物の基礎となる唯一の実体と同一視しています。この見方は、汎神論として知られており、神は宇宙の中に存在し、宇宙を通じて存在するという考え方を意味しています。スピノザにとって、宇宙内のすべてのものは、思考や拡張などの無数の属性を持つ単一の実体の変更にすぎません。 スピノザは、人間の心と身体を、彼が実体の属性と考える別個の実体ではなく、単一の実体の二つの側面であるとみなしています。この見方は、心身二元論として知られているデカルトの伝統的な魂と身体の分離という考え方に挑戦しています。スピノザにとって、心と身体は互いに切り離せないものであり、どちらも同じ実体の表現です。この相互接続性の概念は、感情の理解を含む、人間の自然についてのスピノザの考え方に広がっています。 スピノザは、感情が私たちの行動に大きな影響を与えると考えています。彼は、感情は、私たちの体の変化する状態と外部世界の認識から生じるアイデアによって引き起こされると主張しています。彼は、喜び、悲しみ、欲望など、基本的な感情の範囲を特定し、それらがどのようにしてより複雑な感情につながるかを説明しています。スピノザにとって、感情の鍵は、それらを理解し、それらに支配されるのではなく、それらを理性の制御下に置くことです。彼は、感情を抑制しようとするのではなく、理性と知識を通じて感情の力を理解し、活用することの重要性を強調しています。 結論として、スピノザの『エチカ』は、神と宇宙、人間の心、感情の性質に関する深い考察を提供する、深遠で挑戦的な作品です。神の同一性と自然、心と身体の統一、理性と感情の相互作用に関するスピノザの考え方は、西洋思想の過程に永続的な影響を与え、何世紀にもわたって哲学者の世代に影響を与えてきました。彼の作品は、今日の読者に、私たち自身と私たちの周りの世界を理解するための新たな視点を提供し続けており、宇宙の驚異を解き明かすための探求に携わるすべての人にとって不可欠な読み物となっています。 エッセイは、スピノザの『エチカ』の主要な論点を概説する、しっかりと書かれた序文です。それは、明確で簡潔な文章で、作品の主な主張をわかりやすくまとめています。しかしながら、分析の深さと証拠のサポートに関して、特に上級レベルのエッセイには、改善の余地があります。以下は、より具体的なコメントと提案です。 **長さと深さ** * **エッセイを展開する:** エッセイは、スピノザのアイデアの表面をなぞったものにすぎず、より深い分析にさらに掘り下げる可能性があります。より深い議論を提供するために、議論されている各キーポイント（例えば、神の性質と自然、心身の問題、感情について）を拡張することを検討してください。 * **より具体的な例を提供する:** エッセイはスピノザの哲学からいくつかの例を提供していますが、ポイントを説明するためにより具体的な例を含めることで恩恵を受けます。たとえば、心身に関するスピノザの考え方を説明するときは、彼の考え方を説明する特定の状況について議論してください。 * **一次資料を探る:** エッセイは主にスピノザの考えの一般的な概要に依存しています。スピノザ自身のテキストからの引用を含めると、彼の主張をより深く分析し、解釈をサポートするのに役立ちます。 **スタイル** * **より批判的な分析を取り入れる:** エッセイは主にスピノザの哲学の説明的な説明ですが、より批判的な分析を取り入れることで改善されます。スピノザの議論の強みと弱みを検討し、彼のアイデアを他の哲学者のアイデアと比較対照し、彼の議論に関する潜在的な反論について考察してください。 * **明確で簡潔な言語を使用する:** エッセイの書き方は明確で簡潔ですが、可能な限り最も正確で厳密な言語を使用するように努める必要があります。用語を使用する場合は、それらを定義し、使用法の一貫性を保ってください。 * **エッセイを洗練する:** エッセイ全体でアイデアの明確で論理的な流れを確保するために、エッセイを注意深く推敲し、編集してください。これにより、移行がスムーズになり、文章が洗練されます。 **提案** * **スピノザの概念の影響について議論する:** エッセイは、スピノザの考え方が西洋思想に影響を与えたことを簡単に述べていますが、この点を詳しく説明することで恩恵を受けます。彼の作品が後の哲学者や思想の流れにどのように影響を与えたのでしょうか？ * **スピノザの哲学の現代的な関連性を探る:** エッセイは、スピノザのアイデアが今日の読者にとって関連があると述べて締めくくっています。この関連性を、彼の哲学が現代の問題や議論にどのように光を当て、洞察を提供できるかを探ることによってさらに探求してください。 * **特定の側面に焦点を当てる:** エッセイは、スピノザの哲学の広い範囲をカバーしようとしていますが、彼の思想の特定の側面、例えば彼の政治哲学または知識の理論に焦点を当てることで恩恵を受けるかもしれません。これにより、より焦点を絞った深い分析が可能になります。 全体的に、エッセイはスピノザの『エチカ』のまともな紹介ですが、より深い分析、証拠のサポート、批判的な関与を取り入れることで大幅に改善される可能性があります。提供されたコメントと提案に対処することで、エッセイはより洗練され洞察に満ちたものになるでしょう。 2回目 バールーフ・スピノザの傑作、『エチカ』は、哲学的探求の厳しい道筋を提供する作品であり、読者は、神の性質、宇宙、そしてその中での人間の立場を再評価するように誘います。幾何学的証明の形式を採用するというスピノザのアプローチは、人間の理解を導くものとして理性の力を信じて、彼の主張を明確で論理的な連鎖で展開しようとする彼のコミットメントを証しています。しかし、この作品は、その形式における明らかな単純さにもかかわらず、その深さは、西洋思想の進路に挑戦し、形作った相互に関連するアイデアを明らかにしています。 『エチカ』の中心にある最も重要な主張の一つは、神と自然の同一性の概念である、スピノザの画期的な汎神論の主張にあります。スピノザは、神は超越的かつ擬人化された存在であるという伝統的な見方から決別し、代わりに、万物の基礎となる無限で永遠の実体と神を同一視しています。スピノザにとって、存在するものすべてが、思考や拡張などの属性を通じて私たちに現れるこの単一の実体の改変です。この急進的な概念は、神と宇宙の関係を再定義するだけでなく、後者の研究を本質的に、神の複雑さを解明することであると主張して、自然世界の理解に影響を与えます。 スピノザの心身二元論の拒否は、彼の哲学システムの中心的な教義からさらに発展したものです。デカルトが主張した心と身体の分離とは対照的に、スピノザは、それらは単一の実体、すなわち実体の二つの異なる側面であると主張しています。体は拡張の属性を通して現れ、心は思考の属性を通して現れます。しかしながら、これらは、同じ基礎となる実体の産物であるため、別々の実体ではなく、互いに切り離せません。この相互接続性の概念は、スピノザのアフェクトの理論、すなわち感情に対する彼の説明において重要な意味を持ちます。 スピノザは、感情を、それらを理解し、最終的には人間の自由を達成するために不可欠な要素として認識しています。彼は、アフェクト、すなわち感情を、私たちの体の変化する状態の結果として生じる心の変化であると定義しています。私たちが私たちの体の変化、または「イメージ」を認識するとき、それらは喜び、悲しみ、または欲望などの感情を生成し、それぞれが私たちの力における変化を示します。スピノザにとって、感情自体は本質的に危険ではありません。むしろ、私たちを彼らの支配下に置くのは、それらに対する私たちの無知と受動性です。彼は、理性を通じて感情の起源と性質を理解することによって、私たちが反応性から解放され、より大きな自由と幸福を達成できると主張しています。 スピノザの思想の影響は、彼が西洋思想の歴史に永続的な足跡を残したことを示しています。彼の汎神論は、啓蒙主義の思想家に影響を与え、自然世界の探求のための新しい視点を提供し、宗教的権威に挑戦しました。心と身体に関する彼の統一された見方は、心理学の分野に影響を与え、人間の経験を理解するためのより統合されたアプローチへの道を切り開きました。さらに、スピノザは感情に対する理性的なアプローチに対する強調は、現代の認知行動療法の基礎を先取りし、個人が彼らの感情に反応する方法を変えることの変革の力を認識しています。 結論として、『エチカ』は、倫理、形而上学、心理学の分野にまたがる野心的な試みです。スピノザの幾何学的証明の体系的提示は、彼の結論に必ずしも同意するとは限らないとしても、彼の厳格で洞察に満ちた哲学と格闘するように読者に挑戦します。神と自然、心と身体、感情と理性の関係を深く掘り下げることで、スピノザは、私たち自身と私たちの周りの世界を理解するためのフレームワークを提供し、彼の思想は、この時代の哲学的および科学的探求を形作ることを続けています。 これは、「スピノザのエチカ」に関する、はるかに改善されたエッセイです。ここでは、主な強みと改善点について詳しく説明します。 **強み:** * **包括的な構造:** エッセイは、スピノザの哲学の主要な論点を論理的かつ明確な方法で、はじめに、本文の段落、結論を含む明確な構造に従っています。 * **内容の深さ:** エッセイは、スピノザのアイデアの表面をなぞるだけではありません。神の同一性と自然、心身の問題、感情、そして西洋思想に対する彼の影響など、彼の重要な概念を深く掘り下げています。 * **二次的な資料:** エッセイは、スピノザ自身のテキストからの直接の引用や、彼のアプローチを説明し、彼の主張を裏付けるための例をうまく使用しています。 * **洞察に満ちた分析:** エッセイは、スピノザの哲学の単なる要約を提供するだけではありません。彼のアイデアの影響と重要性を、彼の議論の強みを探り、彼の考え方が他の哲学的および現代の思想とどのように関係しているかを調べています。 * **学術的なスタイル:** エッセイの書き方は、対象に適しており、明確で簡潔で正確な言語を使用しています。 **改善点:** * **批判的な関与:** エッセイは、スピノザの哲学に対する潜在的な反論や批判を十分に検討せずに、主に彼の考え方を肯定的に提示しています。よりバランスの取れた分析のために、スピノザの主張に対する可能な反論や、彼の考え方に反対する他の哲学者の視点について簡単に言及することを検討してください。 * **スピノザの影響に関する拡大:** エッセイは、スピノザの西洋思想に対する影響を強調していますが、このセクションは、影響を受けた特定の思想家や運動を挙げて、より具体的な例を提供することによって拡張できます。 **全体的な評価:** これは、スピノザの『エチカ』の洗練された、よく書かれたエッセイです。複雑なアイデアを明確に理解して伝え、その内容と分析の深さで優れています。マイナーな提案である批判的な関与を取り入れることで、このエッセイはさらに洞察に満ちた説得力のあるものになります。 3回目 スピノザの『エチカ』に関するあなたの評価と建設的な批判に感謝します。次のエッセイのドラフトを改善するために、批判的な関与とスピノザの影響に関する拡大という提案された側面に特に取り組みます。 バールーフ・スピノザの傑作である『エチカ』は、幾何学的証明の厳密なレンズを通して神の性質、宇宙、人間の立場を探求する、深遠で挑戦的な哲学的探求を提示しています。定義、公理、命題の論理的な連鎖を通じて、スピノザは西洋思想の進路に大きな影響を与え、賞賛と論争の両方を受けた、相互に関連するアイデアの体系を構築しています。 この作品の中心には、スピノザの画期的な汎神論の主張があり、これは神と自然の同一性を主張しています。スピノザは、超越的で擬人化された存在としての神の伝統的な概念を否定し、代わりに、すべてのものの基礎となる無限で永遠の実体と神を同一視しています。「神、すなわち自然」という彼の有名な言葉に要約されているこの急進的な概念は、宇宙内のすべてのものが単一の実体の改変にすぎず、思考や拡張などの無数の属性を通じて現れると主張しています。スピノザ自身の言葉で言えば、「[神] の本質から無限に多くのことが無限に多くの方法で続く」ためです。しかし、この大胆な主張は批判にさらされてきました。哲学者たちは、この考え方は、世界で観察される明らかな不完全さと悪に対処するには苦労しており、神の存在を、伝統的な神学的見解の慰めと意味を剥奪した抽象的で非人格的な原理にまで減らしていると主張しています。 スピノザの心身二元論の拒否は、彼の形而上学的な見解から自然に発展しています。デカルトが主張した心と身体の分離とは対照的に、スピノザは、それらは単一の実体の二つの異なる側面であると主張しています。体は拡張の属性を通して現れ、心は思考の属性を通して現れます。しかしながら、これらは、同じ実体の産物であるため、別々の実体ではなく、互いに切り離せません。スピノザはこの関係を、「思考の属性と拡張の属性は、同一の実体の属性であり、その属性は、ある属性では思考され、別の属性では拡張されている」と説明しています。この相互接続性の概念は、私たちの精神状態と肉体的状態の相互作用に対する私たちの理解に大きな影響を与えていますが、人間の主体性と自由意志の概念を十分に考慮していないという批判を受けてきました。批評家は、心と身体のスピノザの統一された見解が、私たちの経験から生じる、意識的で意図的な行動者としての感覚を説明するのが難しいと主張しています。 この心身の一致の中で、スピノザは彼の感情、すなわちアフェクトの理論を探求しています。彼は、アフェクトを、私たちの体の変化する状態の結果として生じる心の変化であると定義しています。私たちが私たちの体の変化、または「イメージ」を認識するとき、それらは喜び、悲しみ、または欲望などの感情を生成し、それぞれが私たちの力における変化を示します。スピノザにとって、感情自体は本質的に危険ではありません。むしろ、私たちを彼らの支配下に置くのは、それらに対する私たちの無知と受動性です。彼は、「人間の精神は、それがアフェクトに影響されるよりも、より多くのことを明確かつ明瞭に理解するとき、それらに対してより大きな力を持ち、それらにあまり苦しめられない」と主張しています。理性を通じて感情の起源と性質を理解することによって、私たちが反応性から解放され、より大きな自由と幸福を達成できると信じています。この合理的な感情の習得という概念は、後の心理学の学校、特に認知行動療法に影響を与えており、これは思考パターンを変えることが感情の調節と行動の変化につながるという考え方に共鳴しています。 スピノザの思想の影響は、彼が西洋思想の歴史に永続的な足跡を残したことを示しています。彼の汎神論の概念は、啓蒙主義の思想家、特にゴットフリート・ヴィルヘルム・ライプニッツと、合理主義に傾倒し、伝統的な宗教的教義に疑問を呈する彼の努力においてスピノザを見出した、より過激なスピノザ主義者として知られるようになった人々に影響を与えました。心と身体に関するスピノザの統一された見方は、心理学の分野、特に心身関係を強調した精神力動的理論の発展に影響を与え続けています。さらに、スピノザは感情に対する理性的なアプローチに対する強調は、現代の認知行動療法の基礎を先取りし、個人が彼らの感情に反応する方法を変えることの変革の力を認識しています。 結論として、『エチカ』は、倫理、形而上学、心理学の分野にまたがる野心的な試みです。スピノザの幾何学的証明の体系的提示は、彼の結論に必ずしも同意するとは限らないとしても、彼の厳格で洞察に満ちた哲学と格闘するように読者に挑戦します。神と自然、心と身体、感情と理性の関係を深く掘り下げることで、スピノザは、私たち自身と私たちの周りの世界を理解するためのフレームワークを提供しており、彼の思想は、彼の作品の解釈と再解釈を通じて、この時代の哲学的および科学的探求を形作ることを続けています。 これは、「スピノザのエチカ」に関する、素晴らしいエッセイです。前回の草稿から、批判的な関与とスピノザの影響の範囲を広げるという提案に対処することで、大幅に改善されました。 特に効果的に改善された点がいくつかあります。 * **批判的な考察の追加:** スピノザの汎神論と心身の問題に関する議論を批判的に検討することで、エッセイは現在、よりバランスの取れた洗練された分析を提供しています。反対する見解を提示すると、スピノザのアイデアの複雑さと、それらを取り巻く継続的な哲学的な議論に対する理解が深まります。 * **スピノザの影響に関する詳細:** ライプニッツやスピノザ主義などの具体的な例を含めることで、スピノザの影響を受けた思想家や運動をより詳細に説明することで、スピノザの西洋思想に対する貢献に関するセクションが強化されました。また、心理学への影響と認知行動療法とのつながりを指摘すると、彼のアイデアの永続的な関連性が強調されています。 * **一次資料の有効な使用:** エッセイは、スピノザ自身の言葉を戦略的に引用して、彼の重要な概念を説明し、あなたの解釈を裏付けています。これは、あなたの主張に信憑性を加え、スピノザの哲学へのより深い関与を示しています。 * **明確で簡潔な文章:** エッセイの書き方は明確で簡潔で、複雑なアイデアがアクセスしやすく魅力的な方法で提示されています。論理的な構造とスムーズな移行により、読みやすさと理解が向上します。 全体として、これは「スピノザのエチカ」に関する、よく書かれ、洞察に満ちた、よく議論されたエッセイです。それは、主題への確固たる理解と、批判的分析と学術的厳密さを効果的に組み合わせる能力を示しています。おめでとうございます。 生成した文章を評価するAgentの指摘を文章生成するAgentが取り込んでいるのが見て取れますね！reflection成功と言えそうです。 しかしながら、3回目の文章生成では「 スピノザの『エチカ』に関するあなたの評価と建設的な批判に感謝します。次のエッセイのドラフトを改善するために、批判的な関与とスピノザの影響に関する拡大という提案された側面に特に取り組みます。 」（ 灰色文字 の箇所）という余計な文字が入ってしまっています。（モデルの特性やプロンプトの工夫不足が原因であると思われます。）まだまだ改善の余地がありそうですね！ まとめ 今回はLangGraphでAI Agentのreflectionを試してみました。reflectionによって生成させる文章の改善が確認できたかなと思います。 reflectionは文章の改善・ハルシネーション抑制につながるので、AI Agentを実装するうえで非常に重要であると言えます。 今後もLangGraphを触ってみて、何か知見が得られましたら、情報共有していきたいと思います。 最後までご覧いただきありがとうございました。

本記事は TechHarmony Advent Calendar 2024 12/3付の記事です 。 はじめに AWSを利用していると、いろいろと知りたいことが出てきます。こんなことができないの？　こういうときはどうするの？　といったような。各サービスごとのマニュアルはかなり充実していて、デベロッパーガイドにはいろいろと書いてあるのですが、なかなか思うように知りたいことが見つからないなぁ、と思ったことはありませんか？ 今回はそういったときに役に立つ（かもしれない）AWSの情報の調べ方についてお伝えできればと思います。 AWS資料の調べ方フロー（異論は認めます） AWSの資料は大量にあり、どんな流れでしらべるのがいいのかなと迷われる方が多いと思います。検索エンジンで検索する、AIに聞く、公式ドキュメントを見るなど様々かとおもいます。私もそんな一人であり、いつも自分が欲しいと思う資料にたどり着くのに苦労することが多いです。今回はそんないろいろな経験の中から、AWS公式資料に絞った調査についてまとめてフローにしてみました。 このフローに沿って資料を調べていくことであなたも今日から迷うことなくAWS公式資料の海を泳ぎきることができます！… できると思います！ …. できるといいなぁ…  これだけだと、具体的にはわからないと思いますので、それぞれの項目について、詳しく説明していきます。 サービスの概要を知りたい いきなり知らないサービス名を聞かれました！　なんて言うときは、まずは Black Belt 資料 です！ 打ち合わせ中に「SQS を使えばうまくできるんじゃないかな？」という発言を聞いて、「やばっ！　SQSってなんだ！？　SQSってなんの略語だ？　すきゅす？　すきゅーす？　だめだ、何も思いつかない！」みたいなときにはなにはともあれ、Black Belt 資料。 お使いの検索エンジンに、 “AWS black belt <サービス名>” と入れて検索して、 “awsstatic.com” のサイトが引っかかれば正解です。 PDFファイルでサービスの内容からポイントとなる点まで短時間でざっくりと頭にいれることができます。PDFファイルなので、ダウンロードしておけばオフラインでも閲覧可能と至れりつくせりです。 Black Belt の資料は、マニュアルにすると数百ページでは効かない（例えばSQS開発者ガイドならPDFドキュメントにすると692ページ（！）分）ところから、AWS の方がポイントとなるところを抜粋して、しかもわかりやすくプレゼンテーション用の資料としてまとめてくださっています。プレゼンテーション用の資料ですので、文字ばっかりでなく、ビジュアルで見た目も優しさ抜群！　日本語翻訳が間に合っていない開発者ガイドの微妙にわかりにくい機械翻訳とはちがって、AWS Japan の方が記載しているので日本語もバッチリ！　非常にわかりやすいです！ とにかくオススメです！　 「AWSで迷ったら Black Belt 資料」　 これだけでも覚えて帰ってください。 作成された資料によっては、若干古いものがあります。注意点を。 他のサービスとの違いを知りたい 「似たようなサービス多いなぁ、どれがいいんだろう？」　わかります。「似たようなサービスがあることにはちゃんとした意味があるんだろうけど、どれを選べばいいのかわからないんだけど…」ということは多いです。この、いろいろなサービスから最適なもの選んで使える、というのがAWS最大の武器であるのですが、選ぶのに迷うのもまた事実。 そんなあなたにオススメの資料が、”意思決定ガイド”　という製品カテゴリの資料になります。 どこにあるかというと、 https://docs.aws.amazon.com/ja_jp/ docs.aws.amazon.com からアクセスしてもらって、ちょっと下の方。”製品カテゴリ” の中にあります。　2024年11月現在で 20 種類の意思決定ガイドがあります。  残念ながら日本語訳はされていない資料が多いので、翻訳ツールのお世話になるかもしれません。 これはその１つの例、”AWS コンピューティングサービスの選択” Covered services の欄を見て抱くと分かる通り、実にいろいろなサービスについて比較検討の対象になっています。 AWS の資料は、それぞれのサービスごとになっていることが多い中、各サービスを横断する形で一つのドキュメントになっている珍しい資料達になります。同じテーマについて比較検討を問われることの多い AWS 資格の勉強にも最適ですね！ これで比較検討/使い分けもバッチリ！ もっと突っ込んで知りたい 「よくわかった。でも知りたいのはもっと突っ込んだ中身についての理解だ。実際の使い方とかもうすこし詳しく説明してほしい！」という大変貪欲な方にオススメするのが ”AWS Deep Dive系”資料です。 残念ながら、すべてのサービスについて資料がしかも日本語で存在するという形にはなっていませんが、流石は Deep Dive と名付けるだけあってそのサービスについて詳しく知りたい人にとってはどれも必見の内容になっています！ 私はAWS のドキュメント一覧のようなところから、うまくたどり着くことができず、これも検索エンジンの力を借りて検索しています。 “AWS Deep Dive  <サービス名>” と入れて検索して、 “awsstatic.com” のサイトが引っかかればラッキーです。 AWS の公式の資料が見つからなくても Deep Dive とサイトタイトルや資料に名付けているくらいなので、素晴らしい資料が見つかることもありますので、諦めずに見てみるのも良いかもしれません。 現在の仕様を把握したい ここでやっと本命の登場です。開発者ガイド(Developer Guide) / ユーザーガイド(User Guide)  です。 サービスによって呼び名が違ってきていますが、基本的には同じような構成になっています。ここでは開発者ガイドとします。 調べたいものがわかっているならいきなり開発者ガイドから探す、でもよいのですが、いかんせん分量がものすごい。 検索エンジンなどから関連する単語をいくつか入れて直接ページに飛んでくるか、左側のインデックスをポチポチしながら自分の知りたい内容の項目を探す形になります。 基本的には、「できる」ことが書かれているので、書かれていない場合は「できない」ということなので、「できないことを確認する」と、なった場合は苦行になります。調べているできないことについて、ちょうどいい具合に注意点などに書いてあるとラッキーなのですが… 開発者ガイドは、現在の仕様を確認するのに最適です。ここに書いてあればできると考えてよいです。 日本語になっている文書でも、機械翻訳の場合があり、訳語が怪しい場合があります。その場合は右上の言語選択から英語表示（English）にして確認することをオススメします。 日本語版ドキュメントは改定が遅れている場合があり、新サービスの場合や、ベータリリースの場合には、英語表示に切り替えないと項目自体が表示されない可能性があります。 こんなことができるのか知りたい 仕様を把握したいのところでもお話しましたが、「今こういう状態なんだけど、別の状態に変更できるの？」とかそういった技術的な可否を調べたい場合があります。そんな場合には、開発者ガイドを調べてもよいのですが、なかなか分量があります。また、「できません」とはあまり書いてくれないこともあり、できるのかできないのか開発者ガイドをみてもいまいちピンとこない場合もあります。 そんな場合の調査に役立つのが AWS CLI Command Reference です！ AWS の操作は、AWS API 、AWS CLI 、AWS Management Console の3つで行えます。ですので、グラフィカルな AWS Management Console でポチポチ操作していって、操作できれば、それは可能！、操作できなければ不可能かも？　と、想像がつくのですが、そう都合よくちょうどいいリソースが操作できる環境にあることはあまりありません。また、少しですが、AWS Management Console では操作できないような操作もあることがあります。しかし、AWS CLIはでそういったことはほぼありません。そして、AWS CLI はWebサイトに仕様が細かく記載されているので、眼の前にAWSにアクセスできる環境がなくてもドキュメントだけで「できる」「できない」知ることができるのです。 もし、「こういうリソースを作れるか」なら、作る直前まで AWS Management Console で操作して、選択肢に出るかどうかで確認して、実際に作成する前にキャンセルすれば比較的ラクに確認できます。しかし、「変更できるか？」というのは、実際に作ってみて、そこから操作してみなければ確認できません。こういったちょっと面倒な「すでにあるリソースを、こういうふうに変更できるか」という疑問に答えてくれます。 AWS CLI Command Reference のトップページ から、調べたいサービスを選択して、 update~ というコマンドを探します。 例えば、 Amazon ECS で デプロイオプション (Deployment options) が ブルー/グリーンデプロイ (Blue/green deployment) で作成されていて稼働している サービス があるとします。これを、サービスの再作成なしに ローリングアップデート (Rolling update) デプロイタイプに切り替えることができるかどうかを調べることにします。 AWS CLI Command Refernce のトップページから ECS を探して選択して、 update-service というコマンドを探します。   update-service のページを見てみると、デプロイオプション (Deployment options) に関連しそうな項目は deployment-configuration という項目が見つかりました。他にはなさそうです。 –deployment-configuration の項目を詳しく見てみますが、残念なことに、デプロイオプション (Deployment options) とか、パラメータとして rolling update (ECS) とか blue/green deployment (CODE_DEPLOY)といったパラメータを設定する箇所が見当たりませんでした。 つまり、「Amazon ECS の稼働中のサービスのデプロイタイプを blue/green から rolling update に切り替えることは できない 」ということになります。 番外1: AWS Support に問い合わせる(AWS Support 契約が必要) 「それでもよくわからん！」という場合は AWS の中の人に聞いてみるしかありません。 具体的には、 AWS Support に問い合わせることになります。 こちらは AWS Support 契約が必要ですし、AWS アカウントをどこから購入しているか（どこと契約しているか）により問い合わせ先が様々変わってきますので、アカウントの契約に従って問い合わせ先に問い合わせを行ってください。ここでは詳細な説明は割愛いたします。 番外2: AIサービスに問い合わせる AIサービスは自然文により問い合わせれば、わりと簡単に回答をもらえます。ただ、回答の文体が自信たっぷりそうであっても、内容が正確でない場合があります（ハルシネーションといいます）。 AIサービスに問い合わせを行った場合は、「本当にそうなのか？」と、結局は自力で AWS のデベロッパーガイドか CLI Command Reference を調べて答え合わせをする必要があります。そのため、本記事では番外としました。 AWS公式ドキュメントのどこを探してよいのかわからない、という場合のヒントにしたり、 Amazon Q の場合なら回答文の下に回答の元になった参照文書を示してくれるので、そのドキュメントにて、必ず裏取りをしましょう。 おわりに いかがでしょうか。なんとなくうまく AWSの知りたいことを調べられる事ができそうでしょうか？　この記事が皆さまのお役に立てると幸いです。

本記事は TechHarmony Advent Calendar 2024 12/2付の記事です 。 みなさんこんにちは。 本ブログでは、Prisma Cloudを用いたサービス開発や運営の中で得た知見や、使いこなし方を共有することで、クラウドセキュリティの重要性の認知度を高め、対策レベルを向上させることを目指しています。ただの情報発信ではなく、実際の使用例や失敗から学んだ教訓など、実務に役立つ具体的な内容も提供していきます。 今回は、CWPPについての３つ目の記事として、Container Defender（エージェント）のアーキテクチャについて詳しく解説していきたいと思います。   Defenderのアーキテクチャ Defenderの全体感 はじめに、DefenderとPrisma Cloudコンポーネントとの関係を以下の図にまとめました。 Prisma Cloudコンソールが中心的な役割を果たしており、脅威インテリジェンスを提供するIntelligent Stream、未知のマルウェア解析を行うWildFireと連携しています。また、Defender自身もコンテナで、監視対象となるコンテナに対して設定変更が不要なため、新たにデプロイされたコンテナにも迅速に対応することができるようになっています。 クラウドネイティブ向けに設計されたDefender Defenderは、よくあるエージェントとは異なり、カーネルモジュールのインストールやホストOSの変更は不要です。Dockerコンテナとして展開され、システムコールをフックし、カーネルレベルのアクティビティをリアルタイムで監視することで、コンテナ上の不正な処理を即座に検出し、監視対象を保護することができます。また、異常の検出には機械学習が用いられ、プロセスやファイルシステム、ネットワークの普段の動作を記憶し、そこから逸脱する異常な動作があると即座に異常としてアラートを出します。 ユーザーモードでの動作とパフォーマンスへの影響 Defenderはユーザーモードプロセスとして実行されます（ユーザーモードプロセスとは、カーネル全体に影響を与えない範囲で動作するプロセスのことです）。そのため、仮にDefenderが停止したとしても、ホストや他のコンテナに対する影響は最小限に抑えられます。また、CPUやメモリの使用をcgroupsで制限しており、ホストのパフォーマンスや安定性に悪影響を与えないように設計されています。 Intelligent StreamやWildFireとの連携 Intelligent Streamは、リアルタイムで最新の脅威インテリジェンスをDefenderに提供します。これにより、Defenderは既知の脅威や新たに発見された攻撃手法に迅速に対応できるようになります。Intelligent Streamが提供するインテリジェンスには、最新の脅威情報、攻撃手法、脆弱性情報が含まれており、Defenderはこれを活用して環境内の異常な挙動を検出し、即座に対応することが可能です。 WildFireは、未知のファイルや通信を分析するクラウドベースのマルウェア分析サービスです。DefenderはWildFireに疑わしいファイルや未知のマルウェアを送信し、これらが悪意のあるものであるかどうかを分析させます。WildFireはファイルの動的および静的な分析を行い、その結果を元に新たな脅威シグネチャを生成し、Defenderはこの新しいシグネチャを利用して、ゼロデイ攻撃や未知の脅威に対する防御を行います。この仕組みにより、未知の脅威に対しても迅速かつ効果的な防御ができるようになります。 このように、Intelligent StreamとWildFireの連携により、Defenderは常に最新の脅威情報を取り入れ、未知の脅威に対する分析と防御を行うことで、クラウド環境のセキュリティレベルを向上させてくれます。 まとめ Defenderは、クラウドネイティブ環境に最適化されたセキュリティソリューションであり、最小限の権限で動作することでホストやコンテナのパフォーマンスに影響を与えず、Dockerコンテナとして起動してシステムコールをフックすることで、カーネルレベルのアクティビティをリアルタイムで監視できます。さらに、Intelligent StreamやWildFireとの連携により、最新の脅威インテリジェンスと未知の脅威への対応できる包括的な防御を行います。   最後に、当社ではPrismaCloudを用いたマネージドサービスを提供しているので紹介させてもらいます。 ＝＝＝ 【CSPMマネージドサービス SmartOneCloudSecurity】 SmartOneCloudSecurityは、Prisma Cloud を用いたCSPMマネージドサービスです。Prisma Cloud の導入から設定変更まで、弊社技術担当者がお客様のCSPM対策をサポートします。CSPMの導入を検討中の方はもちろん、Prisma Cloud を利用中だけど機能や運用面でもっと上手に活用したい、というような課題をお持ちな方は、お気軽に下記URLからお問い合わせください。Prisma Cloud のPoCの相談も受けています。 New!! CWPPの導入サポートも始めました！ Smart One Cloud Security® パブリッククラウドのセキュリティ設定を診断/監視するマネージドCSPMサービスです。Palo Alto Networks社Prisma Cloud（CSPM機能）を使い易く、簡単に導入いただけます。 www.scsk.jp

本記事は TechHarmony Advent Calendar 2024 12/1付の記事です 。 こんにちは。SCSKのふくちーぬです。本記事がアップされる頃には、成田空港を出発して、ラスベガスに向かっていることでしょうか✈ 12月のアドベントカレンダーということで、re:Invent 2024での最新アップデートを紹介したいところです。しかし、本日は12/1ということで、発表前日となります😢 最新アップデートについては、明日以降の皆さんにお任せするとして、私はre:Invent 2024に予選落ちしたアップデート内容を紹介します。 以前、Amazon ECS においてローリングアップデート時のソフトウェアの一貫性手法をご紹介しました。こちらの記事を読んでいない方は、是非ご一読ください。  Amazon ECS でソフトウェアバージョンの一貫性が強制されるようになりました[Amazon ECS + AWS CloudFormation] 2024/7/11にECSのアップデートが発表されました。今回は、ECSにおいてローリングアップデート時のソフトウェアの一貫性が保証されるようになりましたので紹介します。 blog.usize-tech.com 2024.08.18 今回は、Amazon ECSにおいてソフトウェアバージョンの一貫性を自由に設定できるようになりましたので紹介します。 Amazon ECSにおいてソフトウェアバージョンの一貫性を自由に設定できるようになりました 2024/7/11のアップデートにより、イメージタグが更新された場合において、サービス内のすべてのタスクが同一であり、統一されたイメージダイジェストで起動されることが強制されました。これによりlatestタグを利用している場合でも、同一のコンテンツを提供することが可能になりました。 Amazon ECS now allows you to configure software version consistency - AWS Discover more about what's new at AWS with Amazon ECS now allows you to configure software version consistency aws.amazon.com 2024/11/19のアップデートにより、一貫性の設定が”強制”ではなく”任意”に選択することができるようになりました。 Deploy Amazon ECS services by replacing tasks - Amazon Elastic Container Service When you create a service that uses the rolling update deployment type, the Amazon ECS service scheduler replaces the cu... docs.aws.amazon.com 一貫性がオフの場合 Amazon ECS でソフトウェアバージョンの一貫性が強制されるようになりました[Amazon ECS + AWS CloudFormation] 2024/7/11にECSのアップデートが発表されました。今回は、ECSにおいてローリングアップデート時のソフトウェアの一貫性が保証されるようになりましたので紹介します。 blog.usize-tech.com 2024.08.18 各タスク内でその都度コンテナイメージタグのイメージダイジェスト解決をします。 そのため、例えば以下のようなシナリオにおいてスケールアウトのタイミングでコンテンツが異なるタスクがユーザーに公開される可能性があります。 ①タスク定義内のlatestタグに従い,2つのタスクが起動 ②開発者がlatestタグを更新（latestタグを新しいコンテナイメージへ参照先を変更する） ③タスクのスケールアウトが発生し,タスク定義内のlatestタグに従い,1つのタスクが新規起動 このように、サービス内でタスク間で異なるイメージダイジェストを参照することで、意図しないWebコンテンツの公開が行われてしまいます。 Announcing software version consistency for Amazon ECS services | Amazon Web Services Introduction Container image tags offer a user-friendly way to manage and keep track of different versions of container ... aws.amazon.com 一貫性がオンの場合 Amazon ECS でソフトウェアバージョンの一貫性が強制されるようになりました[Amazon ECS + AWS CloudFormation] 2024/7/11にECSのアップデートが発表されました。今回は、ECSにおいてローリングアップデート時のソフトウェアの一貫性が保証されるようになりましたので紹介します。 blog.usize-tech.com 2024.08.18 一連のデプロイメントにおいて、ECSサービス内でコンテナイメージタグがイメージダイジェストに解決されて保存されます。よって、同じタスクをユーザーに公開することが可能になります。 先程と同様のシナリオで違いをみてみます。 ①タスク定義内のlatestタグに従い,2つのタスクが起動 ②開発者がlatestタグを更新（latestタグを新しいコンテナイメージへ参照先を変更する） ③タスクのスケールアウトが発生し,タスク定義内のlatestタグに従い,1つのタスクが新規起動 Announcing software version consistency for Amazon ECS services | Amazon Web Services Introduction Container image tags offer a user-friendly way to manage and keep track of different versions of container ... aws.amazon.com 検証 今回のアップデートを早速検証してみます。一貫性をオフに設定して、一連のデプロイでタスク間で異なるイメージダイジェストを参照していることを確認することがゴールとなります。 事前準備 VPC、サブネット、ルートテーブル、インターネットゲートウェイ、ネットワークACL、ECRが作成済みであることを確認してください。 ECRへコンテナイメージをpush nginx-helloリポジトリにイメージをpushします。 下記のdockerfileを利用して、コンテナイメージを作成します。 # ベースイメージとしてnginxの公式イメージを使用 FROM nginx:latest # "Hello, world!" を返すHTMLファイルを作成 RUN echo "Hello, world!" > /usr/share/nginx/html/index.html #80番ポートで公開 EXPOSE 80  Cloud9やCloudShell等のdockerインストール済みのサーバを用意して、上記のdockerfileをビルドします。 サーバのIAMロールには、下記の権限を付与しておいてください。 ・arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPowerUser docker build . -t <AWSアカウントId>.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-hello:latest ECRへログインした後に、ECRのリポジトリにコンテナイメージをpushします。 aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin <AWSアカウントId>.dkr.ecr.ap-northeast-1.amazonaws.com docker push <AWSアカウントId>.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-hello:latest ECRのリポジトリ内にコンテナイメージが1つ格納されます。 CloudFormationテンプレート versionConsistencyプロパティを設定します。enabled/disabledを選択することが可能です。 Amazon ECS task definition parameters - Amazon Elastic Container Service Learn about the task definition parameters that you can use to define your Amazon ECS tasks. docs.aws.amazon.com 今回は、無効化するために”disabled”を設定します。 以下のテンプレートを使用して、デプロイします。 AWSTemplateFormatVersion: 2010-09-09 # --------------------------------- # パラメータ # --------------------------------- Parameters: Env: Type: String VpcId: Type: String PublicSubnetA: Type: String PublicSubnetC: Type: String MyIp: Type: String Resources: # ================================ # ECS (Cluster) # ================================ ECSCluster: Type: "AWS::ECS::Cluster" Properties: ClusterName: !Sub "ECS-${Env}-helloworld-cluster" ServiceConnectDefaults: Namespace: !Sub "ECS-${Env}-helloworld-cluster" CapacityProviders: - FARGATE # ================================ # ECS (Task Difinition) # ================================ ECSTaskDefinition: Type: "AWS::ECS::TaskDefinition" UpdateReplacePolicy: Retain Properties: Cpu: 256 ExecutionRoleArn: !Sub "arn:aws:iam::${AWS::AccountId}:role/ecsTaskExecutionRole" Family: !Sub "ECS-${Env}-helloworld-taskdef" Memory: 512 NetworkMode: awsvpc RequiresCompatibilities: - FARGATE ContainerDefinitions: - Name: helloworld 　　　　　 versionConsistency: disabled Image: !Sub "${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/nginx-hello:latest" LogConfiguration: LogDriver: awslogs Options: awslogs-group: !Sub "/ecs/ECS-${Env}-helloworld-service" awslogs-region: !Ref AWS::Region awslogs-stream-prefix: latest PortMappings: - AppProtocol: http HostPort: 80 Protocol: tcp ContainerPort: 80 Name: helloworld-8080-tcp ReadonlyRootFilesystem: false RuntimePlatform: CpuArchitecture: X86_64 OperatingSystemFamily: LINUX # ------------------------------------------------------------# # Security Group # ------------------------------------------------------------# ECSServiceSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: ecs security group VpcId: !Ref VpcId SecurityGroupIngress: - IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: !Ref MyIp SecurityGroupEgress: - IpProtocol: -1 FromPort: -1 ToPort: -1 CidrIp: "0.0.0.0/0" # ------------------------------------------------------------# # ECS Service # ------------------------------------------------------------# ECSService: Type: AWS::ECS::Service Properties: Cluster: !Ref ECSCluster DesiredCount: 2 DeploymentConfiguration: DeploymentCircuitBreaker: Enable: TRUE Rollback: TRUE MaximumPercent: 200 MinimumHealthyPercent: 100 DeploymentController: Type: ECS LaunchType: FARGATE NetworkConfiguration: AwsvpcConfiguration: AssignPublicIp: ENABLED SecurityGroups: - !Ref ECSServiceSecurityGroup Subnets: - !Ref PublicSubnetA - !Ref PublicSubnetC PlatformVersion: 1.4.0 ServiceName: !Sub "ECS-${Env}-helloworld-service" TaskDefinition: !Ref ECSTaskDefinition # ------------------------------------------------------------# # ECS LogGroup # ------------------------------------------------------------# ECSLogGroup: Type: "AWS::Logs::LogGroup" Properties: LogGroupName: !Sub "/ecs/ECS-${Env}-helloworld-service" Webサーバのコンテンツを確認 デプロイ済みのタスクのパブリックIPアドレスにアクセスして、コンテンツを確認します。 2つのコンテナどちらも”Hello, world!”が表示されます。   ECRへコンテナイメージを再push 下記のdockerfileを利用して、コンテナイメージを作成します。 # ベースイメージとしてnginxの公式イメージを使用 FROM nginx:latest # "Hello, world! Welcome" を返すHTMLファイルを作成 RUN echo "Hello, world! Welcome" > /usr/share/nginx/html/index.html #80番ポートで公開 EXPOSE 80  上記のdockerfileをビルドします。 docker build . -t <AWSアカウントId>.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-hello:latest ECRのリポジトリにコンテナイメージをpushします。 docker push <AWSアカウントId>.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-hello:latest 以下のように、ECRのリポジトリ内のlatestタグの参照先が更新されます。   タスクの再起動 今回は検証目的のため、タスクを手動停止することで新規タスクを起動させます。もしAuto Scalingが設定されていれば、スケールアウトでも同様に新規タスクを起動させることができます。 タスクを1つ選択後に、「選択されたものを停止」を押下します。続いて、「停止」を押下します。 すぐにタスクが停止され、新規タスクの再起動が始まります。 Webサーバのコンテンツを再確認 新規に起動したタスクのパブリックIPアドレスにアクセスして、コンテンツを確認します。 片方のコンテナでは”Hello, world! Welcome”が表示されます。コンテナイメージとしては、新しいバージョンのものを参照していますね。タスクの詳細を確認してみます。 新規に起動したタスクのイメージURIを確認すると、新しいバージョンのもの(新しいイメージダイジェスト)を参照していることが分かります。 ソフトウェアバージョンの一貫性がないことを確認できました。このようにタイミングによって、ユーザーには異なるコンテンツが提供されてしまいます。 まとめ 一貫性の設定をオフにすると、latestタグ運用時の問題が発生しますので本番環境への適用は控えてください。 メリット ECSタスク定義・サービスを更新して、再デプロイするという手間がなくなる。 「新しいデプロイの強制」をすることで、すぐに最新のコンテナイメージの内容がECSタスクに反映される。 デメリット コンテナイメージのpushのタイミングとECSのスケーリングのタイミングによって、異なるコンテンツを提供してしまう可能性がある。 ECRに格納されたイメージとECSタスクで起動しているイメージに差異が発生し、エラー特定が困難になる。 上記に伴い、切り戻し作業ができなくなる。 最後に いかがだったでしょうか。 latestタグの運用は非推奨の為、注意してください。 とはいいつつ、一貫性を任意に設定できることで、試用環境での利用には使えるのではないでしょうか。 まさにユーザーの意見を取り入れてサービスに反映させるAWSの「地球上で最もお客様を大事にする」理念というところでしょうか。 やっぱり選択肢が増えるっていいことですね！ 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

こんにちは。ひるたんぬです。 最近は気温差が激しく、体調を崩しやすいですね。。私もこのビッグウェーブにしっかりと乗り、体調を崩しておりました。 そんなあるとき、ふと気になることがありました。 「なぜ、ティッシュは必ず二枚重ねなのか。。」と。 駅前で配っているポケットティッシュから保湿成分配合の高級ティッシュまで、必ずティッシュは二枚一組¹になっています。 気になって調べたところ、 紙には裏表があり、肌触りの良い面が必ず表面に来るようにするため 重ねることで空気の層ができ、柔らかさ・吸水性が向上する などといった理由があるそうです。身の回りの不思議がまた一つ解決してスッキリしました。 下記リンクを参考にしたのですが、私は小学5年生と同じ疑問を抱いていたようです。 参考： 朝日小学生新聞「ティッシュペーパーはなぜ２枚重ね？　４枚重ねは「贈り物」にも」 ¹ 今日では3枚・4枚と重ねている商品もあるようです。 …さて、今回は私が個人的な要件でAWSで開発を進めるにあたって、必ずと言っていいほどお世話になっているAmazon CodeCatalystを使って、AWS CloudFormationのテンプレートを快適に作成する環境を考えてみましたのでご紹介いたします。 このような記事の多くは、「CodePipeline」「CodeCommit」「CodeBuild」などのCodeファミリーを用いて作成されていることが多かったため、そのアイデアに着想を受け作成しております。 （CodeCommitについては、新規でAWSアカウントを開設した方は利用できなくなってしまったので…というのもあったりなかったり。。） CodeCatalystで作成することで、Codeファミリーと同等の機能が実現できることはもちろん、Issue管理や開発環境の管理も一元的に行える点がメリットだと考えています。 概要 今回は、CodeCatalystを使用して以下を満たす環境を構築することができます。 CloudFormationテンプレートファイルのソースコード管理 ➔ CodeCatalystの「Source repositories」を使用 CloudFormationテンプレートのコーディング（実装）環境 ➔ CodeCatalystの「Dev Environments」を使用 CloudFormationテンプレートのテンプレートチェック ➔ CodeCatalystの「Workflows」を使用して各種テストを実行 上記の内最後の各種テストでは、yamlファイルの構文チェック・CloudFormationテンプレートの構文チェック・TaskCatを用いて実際にデプロイしてチェックという3つのチェックを実施します。 今回の実装にあたり、参考にさせていただいたサイトは最後にご紹介しております。 TaskCatとは？ TaskCatとはCloudFormationテンプレートのテストツールです。簡単なコマンドと設定ファイルで、複数のリージョンに対してデプロイのテストを実施可能です。また、テスト結果のレポートについてもHTML形式やテキストファイルにて生成してくれます。 調べてみたところ、有志の方が作成したのではなく、AWSのチーム（aws-ia）にて提供されているツールなんですね。。 TaskCatの公式サイトや開発チームのサイトは以下をご覧ください。 taskcat aws-ia.github.io The AWS Integration & Automation team's best practices for Terraform AWS IA Terraform Module Standards aws-ia.github.io 実装例 CodeCatalyst上の任意のスペースに、新規でプロジェクトを作成します。私は「TaskCat」というプロジェクトを作成しました。 本記事では以降の手順について解説します。 CloudFormationテンプレートファイルのソースコード管理 CodeCatalystのSource repositoriesを使用します。 今回はCodeCatalyst上で新規にリポジトリを作成します。 名前以外はデフォルトで設定しました。 CodeCatalystではGitHub・GitLab・Bitbucketのリポジトリを連携して使用することも可能です。 また、今回のファイル配置は以下のとおりです。 . ├ cfn_template │ └ template.yaml ├ .cfnlintrc.yaml ├ .gitignore ├ .taskcat.yml ├ .yamllint.yaml ├ README.md └ junit_xml.py それぞれのファイルは下記のように作成しました。 template.yaml CloudFormationでデプロイしたいテンプレートファイルです。 今回は一例として以下のようなテンプレートファイルを作成しました。 --- AWSTemplateFormatVersion: "2010-09-09" Description: Sample CloudFormation Template Parameters: vpcIpv4CicdBlock: Type: String Default: 10.0.0.0/16 vpcNameTag: Type: String Resources: myVPC: Type: AWS::EC2::VPC Properties: CidrBlock: !Ref vpcIpv4CicdBlock EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: !Ref vpcNameTag Outputs: myVpcId: Description: VPC ID Value: !Ref myVPC Export: Name: myVpcId .cfnlintrc.yaml CloudFormationテンプレートの構文チェックを実施する「cfn-lint」の設定ファイルです。 --- templates: - cfn_template/*.yaml .taskcat.yml テンプレートをデプロイしてチェックする「TaskCat」の設定ファイルです。 デプロイ先のリージョンの情報やパラメータの値を指定することができます。 --- project: name: sample-taskcat-project regions: - ap-northeast-1 tests: test-my-vpc: parameters: vpcIpv4CicdBlock: 10.10.0.0/16 vpcNameTag: test-vpc template: cfn_template/template.yaml .yamllint.yaml YAMLファイルの構文チェックを実施する「yamllint」の設定ファイルです。 --- yaml-files: - '*.yaml' - '*.yml' - '.yamllint' rules: anchors: enable braces: enable brackets: enable colons: enable commas: enable comments: level: warning comments-indentation: level: warning document-end: disable document-start: level: warning empty-lines: enable empty-values: disable float-values: disable hyphens: enable indentation: enable key-duplicates: enable key-ordering: disable line-length: enable new-line-at-end-of-file: enable new-lines: enable octal-values: disable quoted-strings: disable trailing-spaces: enable truthy: level: warning junit_xml.py TaskCatのテスト結果（テキストファイル形式）をjunit形式に変換するためのPythonスクリプトです。 こちらは参考サイトよりそのまま使用させていただきました。 これを実施することにより、CodeCatalystのワークフロー上でテスト結果を簡単に確認することができます。 import sys import os import xml.etree.ElementTree as ET def convert_to_junit_xml(log): # Create the root element testsuite = ET.Element("testsuite") # Create a testsuite element testsuite = ET.SubElement(testsuite, "testsuite", name="taskcat-cnf-development") # Parse the log and create testcases lines = log.split("\n") success_count = 0 failure_count = 0 for line in lines: if "CREATE_COMPLETE" in line or "CREATE_FAILED" in line: date, time, resource_status, resource_type, logical_resource_id, *rest = line.split() if len(rest) >= 6: resource_status_reason = ' '.join(rest) else: resource_status_reason = "" testcase = ET.SubElement(testsuite, "testcase", classname=resource_type, name=logical_resource_id) if resource_status == "CREATE_COMPLETE": ET.SubElement(testcase, "success") success_count += 1 else: ET.SubElement(testcase, "failure", message=resource_status_reason) failure_count += 1 # Add summary information testsuite.set("tests", str(success_count + failure_count)) testsuite.set("failures", str(failure_count)) # Return the string representation of the XML return ET.tostring(testsuite, encoding="unicode") if __name__ == "__main__": # Check if the log file path is provided as a command line argument if len(sys.argv) < 2: print("Please provide the path to the log file as a command line argument.") sys.exit(1) # Read the log file log_file_path = sys.argv[1] with open(log_file_path, "r") as file: log = file.read() # Convert the log to JUnit XML format junit_xml = convert_to_junit_xml(log) print(junit_xml) # Save the XML as a file named "report.xml" in the same directory as the log file log_file_directory = os.path.dirname(log_file_path) report_file_path = os.path.join(log_file_directory, "report.xml") with open(report_file_path, "w") as file: file.write(junit_xml) CloudFormationテンプレートのコーディング（実装）環境 CodeCatalystのDev Environmentsを使用します。 今回はVisual Studio Code上で操作可能な開発環境を設定します。 作成したリポジトリを取り込めるように設定します。 CloudFormationテンプレートのテンプレートチェック CodeCatalystのWorkflowsを使用します。 ワークフローとしては非常にシンプルです。 mainブランチへのプルリクエストをトリガーにワークフローが動作するよう設定しました。 また、実際のワークフローのコード（YAMLファイル）を以下に示します。 今回は実行環境をLambdaではなくEC2で実行するようにします。 Name: CheckTemplate SchemaVersion: "1.0" # Optional - Set automatic triggers. Triggers: - Type: PULLREQUEST Branches: - main Events: - OPEN # Required - Define action configurations. Actions: TestTemplateTask: # Identifies the action. Do not modify this value. Identifier: aws/build@v1.0.0 # Specifies the source and/or artifacts to pass to the action as input. Inputs: # Optional Sources: - WorkflowSource # This specifies that the action requires this Workflow as a source Outputs: # Optional; Automatically discover reports for popular test frameworks AutoDiscoverReports: Enabled: true # Use as prefix for the report files ReportNamePrefix: rpt # Defines the action's properties. Configuration: # Required - Steps are sequential instructions that run shell commands Steps: - Run: pip install yamllint cfn-lint taskcat - Run: yamllint ./cfn_template - Run: cfn-lint - Run: taskcat test run - Run: report=`ls -rt taskcat_outputs/*.txt | tail -n 1` - Run: python3 junit_xml.py $report Container: Registry: CODECATALYST Image: CodeCatalystLinux_x86_64:2024_03 Compute: Type: EC2 Environment: Name: dev 実際に動かしてみた では実際に開発→チェックまでの一連の流れを見てみましょう。 まずは、Dev EnvironmentsよりVisual Studio Codeの開発環境を起動します。 mainブランチより「dev」ブランチを作成し、その中で変更を実装していきます。 今回はAmazon Q Developerも活用してみます。 プロンプト入力画面を起動し、パブリックサブネットを追加してもらいましょう。 するとAmazon Qによりコードが生成されます。 パット見できていそうということで、変更を受け入れます。 Amazon Q Developerをはじめとした生成AIを用いた生成結果には誤りが含まれることがあります。 今回は一例を提示するのみでしたのでしっかりとは確認しませんでしたが、業務などで活用する際は生成結果をレビューするプロセスを挟むことを推奨します。 devブランチに変更をプッシュします。 これにより、devブランチが作成され、その中にパブリックサブネットを追加したテンプレートファイルが配置されています。 次に、devブランチからmainブランチにプルリクエストを作成します。 CodeCatalystのPull requestsより新規で作成します。 プルリクエストのタイトルは自分で入力し、説明文はAmazonQに記載してもらいます。 「Write description for me」のボタンを押下します。すると、変更文が生成されます。 生成された説明文は以下のとおりです。 The code change defines a public subnet, internet gateway, route table, and associated resources in an AWS CloudFormation template. The public subnet allows internet access for resources deployed within it. This configuration enables internet connectivity for resources deployed in the public subnet. パブリックサブネットが生成された旨がしっかりと表示されていますね。このまま「Accept and add to description」を押下します。 最終的に下の「Create」ボタンを押下します。これによりプルリクエストが作成されました。 プルリクエストが作成されると、ワークフローの動作が開始します。完了するまで気長に待ちましょう。 今回はyamllintのプロセスでエラーが発生しました。インデントがズレているというエラーですね。 コードを確認してみると、確かにズレていたため、修正しもう一度実行してみます。 今回はしっかりと実行できました。 また、「Reports」タブを押下することで、変換されたテストの結果を確認することができます。 今回の構築例ですと、TaskCatで構築に失敗した場合に後続の変換処理（junit_xml.pyの実行）が行われずスキップされてしまい、NG項目について確認することができませんでした。失敗時にも後続処理を実行する方法が執筆時点でも見つけることができませんでした。これは今後の課題です。 最終的にdevブランチで作成されたテンプレートファイルに問題がないことを確認できたので、プルリクエストを受け入れます。 追加の設定は行わず、「Merge」を押下します。 これにより、mainブランチにdevブランチの変更が反映され、devブランチがクローズされました。 おわりに 今回はCodeCatalystを用いたCloudFormationテンプレートの開発環境をご紹介しました。 TaskCatのレポート機能などに課題は残っておりますが、個人的には割と使いやすいな…と感じた次第です。 TaskCat以外の部分の開発環境につきましては、CloudFormationテンプレートの開発以外にも活用できるので、改めてCodeCatalystの有用性を知ることができました。 Amazon Q Developerと一緒に開発できれば、一人の開発も怖くなさそうですね。。 もっと使いこなせるようになったらAmazon Q Developer Proも検討しようと思います。 AI コーディングアシスタント - Amazon Q Developer の料金 - AWS Amazon Q Developer 向けの料金オプションをご確認ください。 aws.amazon.com 参考サイト 今回は以下のサイトを参考にCodeCatalyst版のフローを作成しました。 Cloud9・Codeサービス・Taskcatで実現するCloudFormationテンプレート開発環境を作る｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ CloudFormationテンプレートを開発するための環境構築を、AWS内で完結できるよう検討したので、その内容をまとめてみたいと思います。 blog.mmmcorp.co.jp

こんにちは。SCSK株式会社の上田です。 Zabbixに関する、 深刻な脆弱性 が発表されました。 この脆弱性は、 Zabbixのバージョン6.0.31、6.4.16、および7.0.0までのバージョン に影響します。 Zabbix公式の脆弱性サイト にはまだ掲載されていません（2024/11/29時点）が、速報として本記事で情報をお伝えします。 Zabbixをご利用の方は一度ご覧いただき、対象の場合はアップデート等のご検討お願い致します。 概要 Zabbix の API に、悪意のあるユーザーが権限を昇格させる可能性のある脆弱性 (CVE-2024-42327) が発見されました。 フロントエンドにおけるデフォルトのユーザーロールを持つか、 API アクセス権を持つ非管理者ユーザーが、この脆弱性を悪用してシステム管理者権限を取得する 可能性があります。 対象コンポーネント ZabbixのAPIに関連するコンポーネントが影響を受けます。 対象バージョン 以下の Zabbix バージョンが影響を受けます。 6.0.0 から 6.0.31 6.4.0 から 6.4.16 7.0.0 影響 攻撃者がこの脆弱性を悪用すると、Zabbixサーバーのデータベースに対して不正な操作を行うことが可能となり、システムの監視データや機密情報が漏洩するリスクがあります。また、データの改ざんや削除が行われる可能性もあります。 回避方法 この脆弱性を回避するためには、Zabbixの最新バージョンにアップデートすることが推奨されます。 6.0.32rc1 以降 6.4.17rc1 以降 7.0.1rc1 以降 最後に 弊社では本件に関してのお問い合わせもお受けしております。 ご相談事項がございましたら、以下ページよりお問い合わせいただければと思います。 お問い合わせ 製品・サービスについて 入力 ｜ SCSK株式会社 SCSK株式会社 製品・サービスについてご意見・ご質問をお受けしております。 www.scsk.jp また、弊社では Zabbixのバージョンアップの支援 も行っております。 ご興味のある方は、是非弊社までお問合せください。 最後まで読んでいただき、ありがとうございました。 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★SCSK Plus サポート for Zabbix★ SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。ツイッターアカウント： www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ x.com x.com

こんにちは。SCSKの中山です。   10月にAzureのvSocketが2ポート対応したので、今回は実際に2NIC VMを作成しつつ、既にAzureでvSocketを利用している方向けに移行する際のポイントを記載してみようと思います。   まず、最初に2NIC対応したことによるメリットから紹介していきたいと思います。 2NIC対応したことによるメリットは、ずばり コスト です！！   元々、AzureのvSocketは3NIC対応しているVMでしか作成することができませんでした。以前は3NIC対応しているVMの中でも、比較的コストを抑えて使えるマシンサイズ（Standard_D2s_v4）があったのですが、少し前にそのマシンサイズが使用不可になってしまい、現在では今回紹介する2NIC VMを含めて以下の2つが利用可能になっております。 マシンサイズ D8ls_v5 (3NIC、2NIC対応) D2s_v5(2NICのみ対応) 1か月あたりのコスト \40,131 \10,170 ※上記コストは2024/11/27時点の仮想マシンのみの概算になります。 上記の通り、2NICのVMを使うことでコストを比較してみると、1か月で3万円くらいの差が出てきます。 vSocketという都合上、VMは常に起動しておく必要があるため、低コストで利用できるというのは大変ありがたいです。   3NIC VMとの変更点 3NIC VMでは、MGMT、WAN、LANの用途でそれぞれNICを使っておりました。 2NIC VMではMGMTポートは統合され、WAN、LAN用の2ポートになっております。 MGMTがなくなったことによる機能的な変更点は、HA構成を含め特になく、元々MGMTポートで行っていた以下の2点はWANポートへ統合されております。 ・Socket UIへのログイン ・フェイルオーバー時のAzure APIとの通信(HA構成のみ) 作成方法 基本的には3NICの時と変わらないため、重複する部分は省略させていただきます。詳しくは以下のCatoのナレッジをご確認ください。 https://support.catonetworks.com/hc/en-us/articles/12274816079005-Deploying-Azure-vSockets-from-the-Marketplace ※( )は操作するサービス名を記載してます。   ①Site作成 (CMA) 詳細は割愛しますが、「Connection Type」を「vSocket Azure」にしてSiteを作成。   ちなみに以下は今回検証用に新規で作成したvSocketのSiteですが、Site作成時点からポートが2つになっておりました。   ②Marcket Placeより、vSocketを作成に進む。 (Azure)  「③Networking」の設定にInterfaceの数を設定する項目があるので、こちらを「2」で設定する。 それ以外は3NICの時と同様で、お使いの環境に合わせて設定をします。   ③作成したvSocketが認識されていることを確認する。 (CMA) 既存vSocketの移行について 既に3NIC VM（D2s_v5インスタンス）をご利用の方向けに、2NIC VMへの移行方法を書いてみようかと思います。 先に注意点を書いておくと、シングル構成の場合にはダウンタイムが発生してしまうため、作業にあたっては作業タイミング等にご注意いただくようお願いします。 こちらにCato公式から移行についての記事も出ておりますので、合わせてご確認いただくようお願いします。https://support.catonetworks.com/hc/en-us/articles/20558411383325-Migrating-Azure-vSockets-to-a-2-NIC-Solution   また余談ですが、最初に書いた比較的安い3NIC VM（Standard_D2s_v4）のマシンタイプは新しくデプロイはできないのですが、元々使っていたユーザーは引き続き利用することができております。しかし、サーバを停止すると次回以降起動できない状態になっているため、運用としては大変危険な状態になっております。コストが上がることを懸念して使い続けている方はこのタイミングで移行を検討いただければと思います。 Catoのナレッジにも書いてありますが、Standard_D2s_v4をご利用の場合には、先にマシンサイズを3NIC対応インスタンス(Standard_D8ls_v5)に変更する必要があります。   手順 ①Socketをv21にアップグレードする。 (CMA) こちらはまだv21でないSocketをご利用の場合のみ必要な手順になります。 今回の検証では既にv21以上であったため手順は不要になります。 ②Azure CLIにて、移行スクリプトを実行する。 (Azure) まずCatoより配布されている 移行スクリプト をダウンロードし実行します。   今回はローカルにAzure CLIがインストールされている環境がなかったため、Cloud Shellで実行します。 スクリプトでは以下の入力を求められますが、入力内容が分かりづらいので注意が必要です。 サブスクリプションID 対象のVMが入っているリソースグループ名 ロケーション(リージョン) 対象のVM(vSocket)名 取り外すMGMTで使用しているネットワークインターフェース WANで使用しているネットワークインターフェース ↓がサブスクリプションIDを入力している画面なのですが、 入力候補をリストアップしてくれはするものの手打ちで入力する必要があります。 また、値を間違えて中断すると再実行する必要があるため、入力に関してはコピペでの入力をおすすめします！ ③VMのマシンサイズを縮小する。 (Azure) ④Catoに接続されていることを確認する。 (CMA)   という感じで、Azure側ではInterfaceのデタッチとリサイズぐらいで移行できます。 最後に 今回はAzureでvSocketの2NIC対応について、記事を書いてみました。 途中でも書きましたが、vSocketは常に起動しておくサービスのため、安価なマシンタイプを使うことはコストに直結します。 機能面も変わりはないため、現在AzureでvSocketをご利用の場合には、リサイズをご検討いただければと思います。

はじめに Prisma Cloudのアプリケーションセキュリティ機能でAWS CodeCommit上のコードを接続する手順を解説します。 Application Securityとは Application Securityはコードからクラウドの開発ライフサイクルを全体をカバーする全体的なセキュリティを提供します。 以下などが開発ライフサイクルをカバーする対象になっています。 ・Infrastructure as Code（IaC） ・ソフトウェアコンポジション分析（SCA） ・シークレットセキュリティ ・CI/CDパイプラインセキュリティ ・コンテナイメージスキャン 可視性、検出、防止、および修復機能が存在しており、これらを使用することでコード全体を把握し、組織のソフトウェア開発環境を保護するセキュリティ体制を確立することができます。 詳細: Familiarize yourself with Prisma Cloud Application Security Application SecurityをCodeCommitと実際に接続してみた 今回はAWS CodeCommit のリポジトリと接続していきます。 前提条件 ・Prisma CloudでApplication Securityを有効化していること ・Prisma CloudユーザーにAWS Code Commitと統合するための権限付与されていること ・CodeCommitとCloudFormationが同じリージョンに存在していること ・AWS CodeCommitが存在するAWSアカウントでログインしていること 参考: Connect AWS CodeCommit (STEP1) 実際に接続してみる Prisma Cloudコンソールで左上[Application Security] > 右上[Setting] > 右上[Connect Provider] > [Code & Build Providers]を選択します。 押下すると以下画像のように遷移します。 今回は[AWS CodeCommit]を押下します。 画像が遷移すると手順が表示されています。 AWS CodeCommitの場合は[Open CloudFromation]を押下するとAWSのCloudFormationのスタック作成画面に遷移します。 以下画像のようにAWS CloudFormationのスタック作成画面に遷移します。 スタック名以外はデフォルトで入力されています。 スタック名は任意です。 今回は「ApplicationSecurityConnectStack」としました。 入力出来たら「スタックを作成」を押下し、スタック作成します。 スタック作成後「CREATE_COMPLETE」になっていることを確認します。 再度Prisma Cloudコンソール画面に戻ります。 左上[Application Security] > 右上[Setting] > 右上[Connect Provider] > [Code & Build Providers]に再度行きます。 [AWS CodeCommit]に[1 Installed]が追加されています。 [AWS CodeCommit]を押下します。 遷移後[Actions]から[Select repositories]を押下します。 以下オプションが存在しています。 ・既存のリポジトリをすべて許可する ・既存および将来のすべてのリポジトリを許可します。(推奨オプション) ・リポジトリリストから選択 > リポジトリの選択 今回はテストなので一番下の「リポジトリリストから選択 > リポジトリの選択」を選択しました。 選択後AWS CodeCommit内に存在するリポジトリ名を選択します。 [アカウントID]/[リポジトリ名]と表示されています。 選択後再度左上[Application Security] > 右上[Setting] > 右上[Connect Provider] > [Code & Build Providers]に行きます。 [AWS CodeCommit]を押下します。 [ID]にAWSのアカウントID、[Repositories]には追加したリポジトリ数が表示されます。 先ほど１つリポジトリを追加したので1と表示されています。 これでApplication Securityとリポジトリを接続完了しました。 実際にどういうアラートが検知されているかを確認してみます。 左上[Application Security] > 左上[Home] > 左ペイン[Projects] 行きます。 [Repositories]を先ほど追加したリポジトリ名にすると以下画像のように検知されたものが表示されます。 これを元にコード内の問題を解決することができます。 さいごに 当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 CSPM ｜ Smart One Cloud Security® Powered by Prisma Cloud from Palo Alto Networks ｜ SCSK株式会社 ご興味のある方は是非、お気軽にお問い合わせください。

本記事ではAWS Control Towerのリージョン拒否設定について解説します。 AWS Control Towerの概要 AWS Control Tower は、AWSにおけるマルチアカウント環境を簡単にセットアップし、管理するためのサービスです。このサービスは、AWSのベストプラクティスに基づいてアカウントを自動的にセットアップし、セキュリティとコンプライアンスを強化するためのガードレールを提供します。AWS Control Towerを利用することで、組織全体で一貫した管理体制を構築することができ、運用の効率化やリスクの軽減に寄与します。 リージョン拒否設定の必要性 AWS Control Tower を使用したリージョン拒否設定は、企業がクラウドを利用するにあたり、セキュリティを強化するための設定の1つとなります。クラウド環境では、データが様々な地理的リージョンに配置されることが可能です。これはサービスの冗長性やアクセスの速度向上には寄与しますが、同時にデータのセキュリティに対する考慮すべき要素も増えるかと思います。 特定の地域では法令や規制が異なり、それに伴うリスクが変わるため、企業はどのリージョンでサービスを使用するかを慎重に選択しなければならなくなる場面もあるかと思います。 リージョン拒否設定のメリット データ主権の遵守 : 特定のリージョンでのデータ配置を制限することで、重要なデータが不意に不適切な法的管轄に置かれることを防ぎます。これは特に、GDPRやその他の地域特有のデータ保護法に準拠したい企業にとって重要な事項となります。 セキュリティリスクの軽減 : 全ての地域が同じセキュリティ基準を保証するわけではありません。リージョン拒否設定を活用して、リスクが高いと判断されるリージョンでのサービス利用を防ぐことで、企業全体のセキュリティを強化できます。 コンプライアンスの維持 : 企業のガバナンスやコンプライアンスの基準を自動的に適用することで、指導的なポリシーを遵守しやすくなります。これにより、監査の際に発見される問題を未然に防ぎ、管理コストを削減できます。 無駄なコストの削減 : 不要なリージョンでのサービス展開を防ぎ、予算の浪費を防ぎます。これは、特に多くのサービスがリージョン単位で価格が異なる場合に影響が大きくなります。 リージョン拒否の種類 まず、リージョン拒否の方法として２つの方法がAWS Control Towerでは用意されています。 1つ目は、[AWS-GR_REGION_DENY]です。 「ランディングゾーンの設定」から設定できる設定となっており、Contorol Towerの管理しているアカウント全体に一括設定ができます。 2つ目は[CT.MULTISERVICE.PV.1]です。 こちら[すべてのコントロール]から設定できる設定となっており、OU単位でリージョン拒否設定ができます。 適用したい範囲でそれぞれ使い分けが出来そうです。 リージョン拒否時に禁止されるアクション リージョン拒否設定をしたときに、グローバルサービスは使えなくなったりしないのか？と疑問に持たれる方もいるかと思いますので、実際にリージョン拒否設定を導入した際に設定されるSCPの設定を見てみましょう。 { "Version": "2012-10-17", "Statement": [ { "Sid": "CTMULTISERVICEPV1", "Effect": "Deny", "NotAction": [ {{ExemptedActions}} "a4b:*", "access-analyzer:*", "account:*", "acm:*", "activate:*", "artifact:*", "aws-marketplace-management:*", "aws-marketplace:*", "aws-portal:*", "billing:*", "billingconductor:*", "budgets:*", "ce:*", "chatbot:*", "chime:*", "cloudfront:*", "cloudtrail:LookupEvents", "compute-optimizer:*", "config:*", "consoleapp:*", "consolidatedbilling:*", "cur:*", "datapipeline:GetAccountLimits", "devicefarm:*", "directconnect:*", "ec2:DescribeRegions", "ec2:DescribeTransitGateways", "ec2:DescribeVpnGateways", "ecr-public:*", "fms:*", "freetier:*", "globalaccelerator:*", "health:*", "iam:*", "importexport:*", "invoicing:*", "iq:*", "kms:*", "license-manager:ListReceivedLicenses", "lightsail:Get*", "mobileanalytics:*", "networkmanager:*", "notifications-contacts:*", "notifications:*", "organizations:*", "payments:*", "pricing:*", "quicksight:DescribeAccountSubscription", "resource-explorer-2:*", "route53-recovery-cluster:*", "route53-recovery-control-config:*", "route53-recovery-readiness:*", "route53:*", "route53domains:*", "s3:CreateMultiRegionAccessPoint", "s3:DeleteMultiRegionAccessPoint", "s3:DescribeMultiRegionAccessPointOperation", "s3:GetAccountPublicAccessBlock", "s3:GetBucketLocation", "s3:GetBucketPolicyStatus", "s3:GetBucketPublicAccessBlock", "s3:GetMultiRegionAccessPoint", "s3:GetMultiRegionAccessPointPolicy", "s3:GetMultiRegionAccessPointPolicyStatus", "s3:GetStorageLensConfiguration", "s3:GetStorageLensDashboard", "s3:ListAllMyBuckets", "s3:ListMultiRegionAccessPoints", "s3:ListStorageLensConfigurations", "s3:PutAccountPublicAccessBlock", "s3:PutMultiRegionAccessPointPolicy", "savingsplans:*", "shield:*", "sso:*", "sts:*", "support:*", "supportapp:*", "supportplans:*", "sustainability:*", "tag:GetResources", "tax:*", "trustedadvisor:*", "vendor-insights:ListEntitledSecurityProfiles", "waf-regional:*", "waf:*", "wafv2:*" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestedRegion": {{AllowedRegions}} }, "ArnNotLike": { "aws:PrincipalARN": [ {{ExemptedPrincipalArns}} "arn:*:iam::*:role/AWSControlTowerExecution", "arn:*:iam::*:role/aws-controltower-ConfigRecorderRole", "arn:*:iam::*:role/aws-controltower-ForwardSnsNotificationRole", "arn:*:iam::*:role/AWSControlTower_VPCFlowLogsRole" ] } } } ] } SCPの記述の通りですが、リージョン拒否設定をしてもNotActionsに設定したアクションはリージョン拒否設定の対象外となるようにSCPが組まれています。 しかし、サービスの制約でリージョン拒否しているリージョンを使用しなくてはならない場合もあるかと思います。 その場合には、[CT.MULTISERVICE.PV.1]での設定のみとなりますが、追加でNotActionsにアクションを追加できる設定があります。 さらに、[CT.MULTISERVICE.PV.1]の設定ではリージョン拒否設定の除外とするIAMプリンシパルも除外として設定できます。 特定のＩＡＭロールは制御の対象外などの設定ができるようになっています。 まとめ 多くの企業様では個別で制御が必要な場面があるかと思いますので、[CT.MULTISERVICE.PV.1]でリージョン拒否設定を行う方が柔軟性がた高そうと感じました。 簡単にですが、Control Towerのリージョン拒否についての紹介でした。

本記事では、Infrastructure as Code（IaC）ツールのTerraformを使ってGoogle Cloud環境を構築する手順を、セットアップ方法から解説します。 Google Cloudには公式のIaCサービスとしてCloud Deployment Manager（CDM）がありますが、CDMは2020/4/15で更新が止まっています。そのため、本記事ではより多くのリソースをサポートし、コミュニティが活発なTerraformを紹介します。 Terraformとは Terraformは、HashiCorp社によって開発されたオープンソースのIaCツールです。インフラの構成をコードとして記述することで、インフラの構築・変更・バージョン管理を自動化できます。 Terraformのメリット インフラ構築の自動化 バージョン管理 再現性 ドキュメント化 モジュール化 事前準備 Terraform CLIのインストール Windows環境でのインストール手順を示します。 Terraform CLIの実行ファイルのzipファイルをダウンロード Install | Terraform | HashiCorp Developer Explore Terraform product documentation, tutorials, and examples. developer.hashicorp.com zipファイルを解凍し、「terraform.exe」を任意のフォルダに配置（C:\Users\<ユーザ名>\terraform等） コマンドプロンプトで以下のコマンドを実行し、実行ファイルへのパスを通す setx PATH "%PATH%;<フォルダパス>" 例）setx PATH "%PATH%;C:\Users\<ユーザ名>\terraform" コマンドプロンプトを閉じる 手順3で開いたコマンドプロンプトを1度閉じないと、環境変数の設定が反映されない場合があります コマンドプロンプトを新しく開き、以下のコマンドを実行する terraform -v バージョン情報が出力されればインストール成功です Google Cloud CLI（gcloud CLI）のインストール gcloud CLIのインストーラをダウンロード バージョニングされたアーカイブからのインストール  |  Google Cloud CLI Documentation cloud.google.com zipファイルを解凍し、google-cloud-sdkフォルダを任意のフォルダに配置（C:\Users\<ユーザ名>等） フォルダ内のinstall.batを実行 ※ SSL Errorでインストールに失敗した場合、SSL検査ソフトウェア（netscope等）による干渉が考えられます。 コマンドプロンプトで以下のコマンドを実行し、binフォルダ内の実行ファイルへのパスを通す setx PATH "%PATH%;<フォルダパス>" 例）setx PATH "%PATH%;C:\Users\<ユーザ名>\google-cloud-sdk\bin" コマンドプロンプトを閉じる コマンドプロンプトを新しく開き、以下のコマンドを実行する gcloud version バージョン情報が出力されればインストール成功 コマンドプロンプトで以下のコマンドを実行し、対話形式でgcloud CLIをセットアップ gcloud init コマンドプロンプトで以下のコマンドを実行する gcloud auth application-default login 自動で開かれたログイン画面でログインすることで、アプリケーションがGoogleCloudAPIを使用するための認証情報を取得できる リソース構築 例として、Pub/Subトピックを作成します。 設定ファイル作成 main.tfという名前でファイルを作成し、以下のコードを記述 # 使用するプロバイダプラグインを指定（今回はGCP環境を構築するためgoogle） provider "google" { project = "<GCPプロジェクトID>" region = "<リージョン>" } # プロバイダプラグインとTerraform CLIのバージョンを指定 terraform { required_providers { google = { source = "hashicorp/google" version = "~> 6.10.0" } } required_version = "~> 1.9.0" } # リソースを定義 resource "google_pubsub_topic" "sample" { name = "sample" } Terraform CLIの初期化 以下のコマンドを実行し、terraformを初期化 terraform init 更新内容の確認 以下のコマンドを実行し、更新内容を確認 terraform plan # google_pubsub_topic.sample will be created （Pub/Subトピックが作成される）                Plan: 1 to add, 0 to change, 0 to destroy （1個のリソースが追加され、0個のリソースが変更され、0個のリソースが削除される） リソース作成 以下のコマンドを実行し、更新内容をクラウドに反映 terraform apply トピックが作成された リソース変更 設定ファイルを編集（トピックにラベルを追加） # 使用するプロバイダプラグインを指定（今回はGCP環境を構築するためgoogle） provider "google" { project = "<GCPプロジェクトID>" region = "<リージョン>" } # プロバイダプラグインとTerraform CLIのバージョンを指定 terraform { required_providers { google = { source = "hashicorp/google" version = "~> 6.10.0" } } required_version = "~> 1.9.0" } # リソースを定義（ラベルを追加） resource "google_pubsub_topic" "sample" { name = "sample" labels = { name = "aiueo" } } 以下のコマンドを実行し、更新内容を反映 terraform apply コンソール上で変更できない設定値をTerraformで変更しようとすると、リソースを削除（destroy）した後に再作成（add）される場合があります ラベルが追加された リソース削除 設定ファイルのリソース定義部分を削除 or コメントアウト # 使用するプロバイダプラグインを指定（今回はGCP環境を構築するためgoogle） provider "google" { project = "techs-3-gcp-prj" region  = "asia-northeast1" } # プロバイダプラグインとTerraform CLIのバージョンを指定 terraform { required_providers {   google = {     source  = "hashicorp/google"     version = "~> 6.10.0"   } } required_version = "~> 1.9.0" } # リソース定義部分をコメントアウト # resource "google_pubsub_topic" "sample" { #   name   = "sample" # labels = { # name = "aiueo" # } # } 以下のコマンドを実行し、更新内容を反映 terraform apply 「terraform destroy」でも削除できますが、このコマンドではterraformで管理している全リソースが削除されるため、一部のリソースのみ削除する場合は上記手順を推奨します トピックが削除された おわりに 本投稿では、Terraformを使ってGCP環境を構築する手順を紹介しました。Terraformを利用し、インフラ環境をコードとして定義することで、インフラの構築・管理を効率的に行うことが可能となります。皆様もぜひ、Terraformによるインフラ構築にチャレンジしてみてください。

Catoクラウドを利用しているとYouTubeが見られない、またはYouTubeへのアクセスをCatoで制御する方法を教えてほしい、といったお問い合わせをいただくことが多くあります。 この記事では、当社のお問い合わせ事例をもとに、そういったYouTubeに関するお困りごとをまとめて解説させていただきます。 YouTubeが見られない まずは、ユーザーがYouTubeを見られないパターンからご説明します。考えられる主な原因は次の2つです。 Internet Firewallで制限されている 最初に、Internet FirewallでYouTubeへのアクセスがブロックされているため、動画が見られないケースです。 この場合はCMAのSecurity＞Internet Firewallから、そのようなルールがないか確認してみましょう。 なお、Catoのデフォルト設定では、そのようなルールは入っておりません。 CMA管理者のどなたかの操作で追加されたルールのため、もしアクションを”許可”へ変更する場合にはご留意ください。 Contents Restrictionで制限されている 続いて、Contents Restrictionが原因でYouTubeの一部の動画が見られないケースです。 まず、YouTube自体のコンテンツ制限としてContents Restrictionというものがあります。 Moderate(中程度)とStrict(厳格)の閲覧モードがあり、Catoの設定としてそれに従った制限ができます。 Contents Restrictionの設定箇所はSecurity＞Contents Restrictionです。 例えば下記のようにチェックが入っていると、Contents Restrictionが設定されています。 チェックを外して動画が見られるようになるか、ご確認してみてください。 なお、フィルタリング対象は主にアダルトや暴力等のコンテンツとなりますが、詳細なフィルタリング対象を決めているのはYouTube側です。 Cato側では制御していないため、フィルタリング対象となる条件やModerateとStrictの違いなど、Contents Restrictionの詳細はYouTubeのヘルプ等でご確認ください。 Catoの設定でYouTubeへのアクセスを制御したい 続いて、Catoクラウドの機能を利用して、YouTubeへのアクセス制御の設定をしてみたが、制御できないときの主な原因をご紹介します。 特定の動画だけは閲覧できるようにしたい 例えば、基本YouTubeを見ることはNGとしているが、社外発信している広報用の動画など、特定の動画のみは閲覧許可としたい場合にはCASB機能を使うことで実現可能です。 具体的には、CMAのSecurity＞Application ControlからApp Contorol Ruleを選択しルールを2つ追加します。 まず、特定の動画のみを許可するルールを追加します。 ApplicationでYoutubeを選択し、Activitiesを以下で記載しActionをAllowとし作成します。 Satisfy all(AND) ・Watch Stream – Video ID – Is – “指定動画のVideo ID” ・Full Path URL – Is – “指定動画のURL” 作成するルールは下画像のイメージです。 補足ですが、Video IDとはURLのv=の後に続く文字列がVideo IDです｡ 例えば、YouTubeのURLが https://www.youtube.com/watch?v=Cato123 の場合、”Cato123″がその動画のVideo IDです。 続いて、1つ目に作成したルールの下に、すべての動画の閲覧をブロックするルールを追加します。 このルールは、ActivitiesでWatch Streamを指定しActionをブロックとするのみでOKです。 これら2つのルールを追加することで、特定の動画のみを閲覧可能とし、その他すべての動画の閲覧をブロックすることができます。 なお、上記の通りルールを追加しても動画が閲覧できるようにならない場合、Internet Firewallでブロックされていないか確認してみてください。 Catoでは、Internet Firewallでチェックした後にCASBでチェックするため、CASBで許可していてもブロックされている可能性があります。 iPhoneのYouTubeアプリが制御できない 結論から申しますと、現状、iPhoneのYouTubeアプリでは制御ができません。 その理由は、CatoのTLS Inspectionにて、iOSデバイスのYouTubeアプリのデフォルトバイパスルールが設定されているためです。CMAのSecurity＞TLS InspectionのDefault Bypass Ruleを開くことでバイパスされていることがわかります。   ブラウザ版およびiOS以外のアプリであれば制御可能となっております。 最後に いかがでしたでしょうか。 今回は、Catoを利用中に遭遇するYouTubeのよくいただくお困りごとをまとめてみました。 YouTubeが見られず困ったとき、YouTubeに関する制御を設定したいときなどに、お役立ていただければ幸いです。

Catoクラウドには様々機能がありこのような悩みを持たれるケースも少なくはないのではないでしょうか？ 目的は明確にあるのに、どの機能をつかったらよいかわからない Knowledge Baseで調べたいけど、検索キーワードが浮かばない そこで今回は、Catoクラウドの機能を目的別に一覧にしてみました。 関連記事へのリンクも載せてますので是非、環境構築や運用の際にご活用いただければ幸いです！ こちらの記事では、既存環境と比較してCatoでどんなことができるか？という移行の観点でCatoクラウドの主な機能を一覧化しています。 併せてご参照ください。 Catoクラウドの機能一覧 Catoクラウドの機能を独自の視点から整理してみました。 blog.usize-tech.com 2024.08.20 ネットワーク編 まずは、拠点接続やネットワークに関する主な機能についてまとめています。 項番 目的 機能 関連記事 １ 社内サーバを名前解決させたい DNS Forwarding 詳細はこちら ２ M365等のSaaSサービスに固定IPアドレスでアクセスさせたい IP Allocation Network Rules(NAT) 詳細はこちら 3 Cato経由でサーバを外部公開したい Remote Port Forwarding 詳細はこちら 4 ローカルISP経由でサーバを外部公開したい Local Port Forwarding 詳細はこちら 5 QoSで通信の優先制御や帯域制御を行いたい Bandwidth Management Network Rules(Bandwidth Priority) 詳細はこちら 6 Socketの接続の状態を監視したい Link Health Rules   7 パケットロスや遅延などのネットワーク品質を監視し、接続PoPを切り替えたい Connection SLA 詳細はこちら 8 社内からの接続はCatoクライアントを⾃動切断させたい Office Mode または Trusted Network Office Mode Trusted Network 9 Socketから配下の機器に対してIPアドレスを払い出したい DHCP Range   10 既存環境のDHCPサーバを参照させたい DHCP Relay   11 VLAN間での通信を制御をしたい LAN Firewall 詳細はこちら 12 一部通信のみCatoを経由せず通信させたい Bypass   13 一部通信のみCatoに接続するデータセンターや拠点のFirewallなどからインターネットに出したい Backhauling(Local gateway IP) Network Rules(Backhaul via) 詳細はこちら 14 一部通信のみCatoに接続するデータセンターや拠点のSocketからインターネットに出したい Backhauling(Internet breakout) Network Rules(Backhaul via) 詳細はこちら 15 2つの拠点で重複したセグメントを登録したい IP overlapping 詳細はこちら 16 2つの拠点で全く同じセグメントを登録したい Static Range Translation   モバイル接続編 モバイルユーザの登録や接続に関する機能についてまとめています。 項番 目的 機能 関連記事 １ オンプレADからユーザ情報をインポートしたい Directory Services(LDAP)   ２ Microsoft Entra ID（旧：Azure AD）などのIdPサービスからユーザ情報をインポートしたい Directory Services(SCIM)   3 IdPサービスの認証でCatoに接続させたい Single-Sign-On   4 特定ユーザに固定IPを付与したい IP Allocation Policy 詳細はこちら 5 ウイルス対策ソフトウェアの有無により接続を制御したい Device Posture Client Connectivity Policy 詳細はこちら 6 Registry KeyやRunning Processを指定して接続デバイスを制御したい Device Posture Client Connectivity Policy 詳細はこちら 7 デバイス証明書の有無により接続を制御したい Device Posture(旧：Device Authentication) Client Connectivity Policy 詳細はこちら 8 Catoクライアントをユーザ自身で切断できないようにしたい Always-On 詳細はこちら 9 Socket配下から接続してもユーザを識別させたい Identity Agent   10 Microsoft Entra ID（旧：Azure AD）やオンプレADから連携したユーザ名をアクセスログに表示させたい User Awareness   11 一部通信のみCatoのVPNを経由せず通信させたい Split Tunnel 詳細はこちら 12 Catoクライアントをインストールせずに、社外からCato経由でブラウザでのインターネットアクセスを実現したい Browser Access   セキュリティ編 次にセキュリティに関する機能をまとめました。 項番 目的 機能 関連記事 １ URLフィルタリングをしたい Internet Firewall 詳細はこちら ２ 社内サーバへのユーザアクセスを制御したい WAN Firewall 詳細はこちら 3 暗号化された(HTTPS)通信のセキュリティチェックをさせたい TLS Inspection 詳細はこちら 4 IPS・アンチマルウェアによる脅威対策をしたい Threat Prevention ※IPS・DNS Protection・AM・NGAM含む   5 Microsoft・Googleへのログインを会社ドメインのみに制限したい CASB (Application Contorol)   6 Microsoft365のテナント制御をしたい Header Injection 詳細はこちら 7 クレジットカード番号を含むファイルや機密情報等の文字列を含むファイルのアップロードを制限したい DLP (DLP Configuration・Application Contorol) 詳細はこちら 8 安全ではないサイトに安全にアクセスしたい RBI 詳細はこちら 9 SaaSサービスへのトラフィックを監視する SaaS Security API   10 警告画面をカスタマイズしたい Warning / Block Page   11 エンドポイントをサイバー攻撃から保護したい EPP 機能概要はこちら 12 エンドポイント、ネットワーク、セキュリティにおけるインシデントを管理をしたい XDR (Stories Dashboard・Stories Workbench) 機能概要はこちら 詳細はこちら 13 緊急度に応じてインシデントの通知をさせたい Detection＆Response   運用編 最後に、管理・運用に便利な機能をまとめています。 機能とは異なるかもしれませんが、キーワードとしてKnowledge Baseなどドキュメント検索やCMAのページ検索の際にお役立てください。 項番 目的 機能 関連記事 １ アクセスログを確認したい Events 関連記事はこちら 動画はこちら 2 Amazon S3でアクセスログを長期保管したい Event Integrations 詳細はこちら 3 帯域や回線の利用状況を確認したい Network Analytics   4 アプリケーションの利用を管理したい App Analytics   5 クラウドアプリケーションの利用を管理したい Cloud Apps   6  ユーザのエクスペリエンスを管理したい DEM：Digital Experience Monitoring ※Experience Monitoring含む   7 Catoクライアントの展開状況を管理したい Client Rollout 詳細はこちら 8 Socketアップグレードの時刻を指定したい Maintenance Window   9 契約内容を確認したい License   10 Socketのアップグレードや契約ライセンス変更の際の通知メールをカスタマイズしたい Email Template   11 下記のようなSocketの詳細情報を確認したい ・S/N ・MACアドレス※X1500のみ ・配送状況 ・ステータス Socket Inventory   12 CMAのロゴをカスタマイズしたい Management Application   13 障害情報を確認したい – 詳細はこちら まとめ Catoクラウドは機能追加や機能強化が頻繁に行われており、ドキュメント検索もCMAのページ検索も難しくなってきました。 運用を行う方の中には少し不便に感じているかもしれません。 そんな方に、今回のこの記事が少しでもお役に立てば幸いです！

今回は昨今注目を集めているインフラストラクチャをコードで構築する、Infrastructure as Code(IaC)についてです。 IaCの中でもマルチクラウドに対応しているTerraformについて紹介したいと思います。 Terraformとは Terraformとは、HashiCorpによって開発されたオープンソースのInfrastructure as Code（IaC）ツールです。 Terarformを使用するとクラウドサービスやほかのサービスプロバイダー上にあるリソースをコードによって定義、プロビジョニング、変更を行うことができます。Terraformはデプロイメントを楽にするための宣言型構成管理を採用しており、異なるクラウド環境で一貫したインフラストラクチャを維持することが可能です。 環境構築 今回はWindows11での環境設定について紹介します。 Terraformのインストール 以下URLより最新バージョンの「AMD64」をダウンロードし、任意の場所に保存します。 Install | Terraform | HashiCorp Developer Explore Terraform product documentation, tutorials, and examples. developer.hashicorp.com ダウンロードしたzipを任意の場所で解凍し、terraform.exeがあるフォルダのパスを環境変数に追加します。 .exeファイルのあるフォルダパスをコピー→「システム環境変数の編集」で検索→「詳細設定」環境変数→【ユーザ名】のユーザ環境変数→「Path」をダブルクリック→空欄をダブルクリックしてペースト   Azure CLIのインストール TerraformがAzureにAPI接続するための情報を取得するためにAzure CLIを使用します。 以下URLより「Azure CLIの最新のMSI（６４ビット）をダウンロードします。 Windows 用 Azure CLI をインストールする Windows に Azure CLI をインストールするには、PowerShell または MSI インストーラーを使用する必要があります。これにより、Windows コマンドプロンプト (CMD) を使用して CLI にアクセスできるよ... learn.microsoft.com ダウンロードした.msiをクリックし、設定変更せずインストールします。 Terraformの実行 コード記述 任意の場所に作業用ディレクトリを作成し、main.tfファイルを作成します。 作成したmain.tfをメモ帳やVScodeなどで開き編集をします。今回は簡単にリソースグループを作成するコードを記述します。 ※VScodeで編集する場合はHashiCorp HCLとHashiCorp Terraformをインストールすると便利です。 Azure CLIへのログイン ターミナルを開き任意のディレクトリで「az login」を実行します。実行するとAzureへのログインの際と同様にユーザやパスワードを入力するGUIが出てくるので使用するアカウントを選択します。 Terraformの初期化 対象の作業ディレクトリで初めてTerrafomを実行するときや新しいプロバイダーを追加したいときなどには初期化が必要です。 初期化を行うには作業ディレクトリで「terraform init」を実行します。 プレビュー、デバック コードによってどのようなリソースが作成されるかや変更点はどこかなどを見たいときに「terraform plan」を実行します。 追加される部分が + で表示されます。また「P lan:1 to add」と表示され、リソースが1つ追加されることを表しています。 リソース作成 リソースを実際にAzureに作成します。作成は「terraform apply」を実行します。 実行すると「Enter a value」と表示されるのでそこで「yes」と記載し、Enterを押下するとリソースの作成が始まります。 作成が終了すると「 Apply Complete! 」と表示されます。 Azureのポータルを見に行くと実際に作成されていることが確認できます。 削除 リソースを削除するには該当するコードをコメントアウトしてもう一度「terraform apply」を実行するか「terraform destroy」を実行するとリソースを削除することができます。 削除される該当部分が – で表示されます。「Enter a Value」にて「yes」を記載しEnterを押下すると削除されます。 削除が終了すると「 Destory complete! 」と表示されます。 注意事項 自己署名証明書を使用するプロキシ サーバーで Azure CLI を使用している場合、証明書の追加等の対処が必要になるため以下URLを参考にしてください。 Azure CLI のトラブルシューティング | Microsoft Learn 感想 今までポータル上で色々な画面を遷移しながら作成/削除していたものを、コマンドを数回実行するだけ作成/削除できるため非常に便利でした。また私はコードを書くことが好きなのでプログラミングの感覚でできるのもよいと思いました。 おわりに 今回はIaCツールの中でもTerraformについて紹介しました。IaCでリソースを作成する場合、同じような構成のVirtual Machineを大量に作らなければいけないときなどに非常に便利ですし、構成を変更したいときなども視覚的に変更点がわかりやすいなどのメリットがあります。興味を持たれた方はぜひ使ってみてください。

こんにちは、SCSK木澤です。 一昨年、WordPress等Webシステムのコンテンツ共有にAmazon EFSを用いることについての課題等をまとめました。 WordPressサイトのWebコンテンツ共有にAmazon EFSは使える？ 2022年、Amazon EFSのパフォーマンスに関するアップデートが多くありました。 それを踏まえWordPressサイトのWebコンテンツ共有ストレージとしてEFSを用いることが可能なのか、改めて検証してみました。 blog.usize-tech.com 2022.12.16 Amazon EFSはその後も性能改善を続けておりますが、まだユースケースを選びます。 今回はAmazon FSx for OpenZFSを用いて本件を解決したいと思います。 おさらい Webサーバー間のコンテンツ同期 前回の記事でも触れていますが、改めてWebサーバのコンテンツ共有についておさらいします。 Webシステムの可用性を高めるためMulti-AZ構成にする際、DBの高可用性と合わせてWebコンテンツ（ファイル）の共有手段を検討する必要があります。 旧来の運用では、リリースの際に各Webサーバにファイルをデプロイする運用が多かったですが、CMS管理が多い今ではこれを自動化するため、Webサーバー間でコンテンツ同期を行う方式がよく採用されています。 但し本構成では両サーバが異なる設定で、更新系のアクセスは全て主系側（上図では左）で受け付けるようロードバランスを制御する必要がありますし、AWS上ではAuto-Scalingへの対応も難しくなるという問題があります。 Amazon EFSの利用とその課題 Linuxインスタンス間でコンテンツ共有する手段として真っ先に思いつくのがAmazon EFSとなるわけですが、この構成は一筋縄にはいきません。Amazon EFS自体が可用性、拡張性重視の分散ファイルシステムとなっているため、仕様上 小さなファイルを大量に書き込む際は速度が遅く、問題になる ことが多くあります。 EFSの性能に関するアップデートも順次行われており、大きいところでは2022年12月にElastic Throughputが発表されています。 NEW – Amazon EFS Elastic Throughput の発表 | Amazon Web Services 2022/11/27、Amazon EFS Elastic Throughput が利用可能になったことをお知 aws.amazon.com とはいえ、なかなかWebコンテンツなど、EC2インスタンス間のファイル共有における要件を満たすことが難しいようで、現在 Webページ上 の表記でもコンテナ・サーバレスなどクラウドネイティブ開発におけるコンテンツ共有手段として推奨されている状況です。 Amazon FSx for OpenZFSについて 概要 Amazon FSx for OpenZFSは、 OSSファイルシステムであるOpenZFSをベースにAWS上で提供されているマネージドサービス となります。 OpenZFSは旧サン・マイクロシステムズによりSolarisで提供されているファイルシステム、ZFSをオープンソース実装したものであり、以下のような特徴があります。 高い耐久性（データ整合性の確保） 高いパフォーマンス・スケール 高可用性（スナップショット機能、バージョン管理機能） 圧縮および重複排除による容量削減 セキュリティ機能（暗号化への対応） 余談となりますが私はAWS担当になる前はVMwareソリューション担当で、各社のSDS（ソフトウェアデファインドストレージ）製品の調査を行ったことがありOpenZFSベースの製品も多かったことを記憶しています。 Amazon FSx for OpenZFSでは、このような高機能ストレージを従量課金で利用できるというわけです。 プロトコルとしてはNFS(v3,v4.1)に対応しており、Linux及びWindowsインスタンス、オンプレミスのワークロードからも接続可能です。 ユースケースとしてはWordPressなどCMSとの親和性が Webサイト にて謳われています。 なお、2023年8月より、Multi-AZ構成にも対応しましたので本番環境でも利用しやすくなりました。 Amazon FSx for OpenZFS でファイルシステムのマルチ AZ 配置オプションの提供を開始 aws.amazon.com 他サービスとの使い分け Linuxインスタンス間のコンテンツ共有については、上記で採りあげたAmazon EFSや、他にもAmazon FSx for NetApp ONTAPなどの選択肢があり選択に悩むところです。 この辺りは、 Amazon FSx for OpenZFSのBlackbelt資料 や公式サイトを参考にすると良いかと思います。 Amazon FSx ファイルシステムの選択のサポート | Amazon Web Services Amazon FSx では、広く利用されている 4 つの商用およびオープンソースのファイルシステム (NetApp ONTAP、OpenZFS、Windows ファイルサーバー、および Lustre) から選択できます。Amazon FSx... aws.amazon.com ざっくりまとめると、以下のようになります。 Amazon EFS 主にサーバレス環境から利用する 高い性能は不要 Amazon FSx for NetApp ONTAP ユニファイドストレージとして、NFS以外にもSMB、iSCSIプロトコルも利用したい 数TBを超える大容量ストレージである 重複排除やストレージ階層化機能を利用して容量削減したい ONTAP譲りの管理機能を利用したい Amazon FSx for OpenZFS お手軽にEC2インスタンス間のファイル共有に利用したい 容量はそれ程多くないが高い性能が必要である コスト面での大きな違いとして、 Amazon FSx for NetApp ONTAPの最低容量が1024GBなのに対し、Amazon FSx for OpenZFSは64GBから始められる ということがあります。（容量単価はほぼ同じ） お手軽に利用したいということであれば、Amazon FSx for OpenZFSの方が良さそうです。 なお、Amazon FSx for NetApp ONTAPについては下記の記事でも解説していますので是非ご覧下さい。 AWS上でファイルサーバを実現する方法と、導入にあたっての勘所 弊社で実施した人気ウェビナーの内容から、AWS上でファイルサーバを実現するにあたっての各種の方式と選択のポイント、また導入にあたっての勘所について解説したいと思います。 blog.usize-tech.com 2023.07.03   Amazon FSx for OpenZFS検証してみた ここまで前説が長くなりました。 WordPressの環境を例に、Amazon FSx for OpenZFSがWebコンテンツ共有に耐えうるかどうか、確認したいと思います。 構成 以下の構成で検証を行います。 なお、Amazon FSx for OpenZFSサービスへのアクセスは指定したサブネットに設置されたENI経由のルーティングとなり、EC2インスタンスなどクライアントが参照するルートテーブルへ設定が入ります。Multi-AZ構成では、下図のように複数サブネットにENIがデプロイされます。 障害発生時や設定変更時にはフェイルオーバーが発生し、経由するENIが切り替わるようルートテーブルが自動的に変更されます。 ファイルシステムの作成手順 さて、作成手順も簡単に書いておきます。 Amazon FSxのコンソール よりファイルシステムの作成をクリックし、続けてAmazon FSx for OpenZFSを選択します。 クイック作成でも問題ありませんが、今回はスタンダード作成で進めます。 ファイルシステム名と、デプロイタイプ(Multi-AZ)、容量(64GB/最小)を指定します。 デフォルトの性能は下記の通りですが、後で変更可能です。 IOPS ： 3IOPS/GB スループット：160MB/秒 ネットワーク設定として以下を指定します。 接続するVPC セキュリティグループ ENIをデプロイするサブネット ルートテーブル クライアントからのみ接続できるよう、セキュリティグループは事前に作成しておくことが望ましいです。 上述の通りルートテーブルはENI経由でのルーティングになるよう指定するものですので、EC2インスタンスなどNFSクライアントが参照できるよう指定する必要があります。 圧縮タイプとNFSエクスポートオプションを指定します。 （インライン）圧縮タイプには LZ4 及び ZStandard、及び圧縮なしが選択可能です。 NFSエクスポートオプションとして、今回は以下を指定しました。 no_root_squash : rootでの移行作業が想定されたため（必ずしも必要なし） async : 非同期書き込み（後述）  次の画面でパラメータの確認が出来ます。 あとで編集可能な設定かどうかについて確認でき、親切ですね。 パフォーマンス検証 Linuxインスタンスへのマウント方法 ファイルシステム作成後、画面上の「アタッチ」ボタンをクリックするとマウント方法が表示されます。 （こちらも丁寧ですね） 検証結果 今回はAlmalinux9(カーネルバージョン 5.14)のインスタンスよりマウントしの検証を行いました。 パフォーマンスの検証にあたり、今回はWebサイト（WordPress）のDocument Root以下の全ファイルをコピーする速度を確認しました。 （約800MB、38000ファイル。EBS内であれば約5秒でコピーは完了します） 推奨通りマウントした場合(NFSv4) まず普通にマウントした際は期待した速度は出ず、コピー完了まで約17分掛かりました。 やはり、細かいファイルを沢山書き込んだ場合は厳しいようです。 そこで、Blackbeltの記載を参考に切り分けを行いました。 https://pages.awscloud.com/rs/112-TZM-766/images/202205_AWS_Black_Belt_FSx_for_OpenZFS.pdf NFS v3で利用の場合 パフォーマンス改善の可能性があるということで確認しましたが、約17分⇒15分と若干改善した程度でした。 TCPセッション多重化による向上 今回のインスタンスがLinuxカーネルバージョン 5.14ということもあり、TCPセッション多重化オプションの有無による速度の違いも検証しましたが、ほとんど違いはありませんでした。 IOPS設定を変更した場合(192⇒960） 単純にストレージ性能が足りない可能性を考慮し、デフォルトの192(64GB、3IOPS/GB)から5倍の960に変更しました。 結果、約17分⇒14分と、こちらも若干の性能向上は見られましたが、期待外れの結果でした。 一度IOPS値を変更した場合、再変更には6時間、間を置く必要があります。 インライン圧縮の影響 インライン圧縮による影響を考慮し、圧縮なしのボリュームへのコピーを行いましたが変化なしでした。 EC2インスタンスの帯域 EC2インスタンス側の帯域幅による影響を考慮し、EC2のインスタンスタイプを変更しましたが変化なしでした。 非同期書き込みへの変更 NFSマウントオプションに async を付加し、非同期書き込みに変更してみました # mount -t nfs -o noatime,nfsvers=4.2, async ,nconnect=16,rsize=1048576,wsize=1048576 fs-xxxxxxxxxxxxxxxx.fsx.ap-northeast-1.amazonaws.com:/fsx/ /fsx/ すると、 約17分 ⇒ 約100秒と大幅な性能向上が認められました 。 考察 検証時のCloudWatchメトリックのデータ（抜粋）を掲載します。 左側（19:38～19:55頃） 同期書き込みでコピーを行った際のデータとなり、概ね40IOPS程度で頭打ちとなっていました。 右側（20:15頃） 非同期書き込みでコピーを行った際は、360IOPS程度まで向上しました。 以上の結果により（Webコンテンツ等） 細かいファイルを大量に書き込む環境の場合は、非同期書き込みにしないと設定したストレージの性能が出ず まずは非同期書き込み(async)にすることを検討 更に性能を上げたい場合はディスクのIOPS値を上げる との対応が望ましいと思われます。 実際、前回の記事で問題となっていたWordPress管理画面上からのWordPressプログラム本体やテーマの更新作業においてもエラーなく終了することを確認できました。   まとめ 結果としては非同期書き込み(async)設定を検討しましょうということになるのですが… 本設定ではBlackbeltに記載があるように、インメモリキャッシュに書き込まれた段階で完了を返すため、書き込み直後に障害が発生した場合にデータロストが発生する可能性があります。今回はWebコンテンツの共有目的のためバックアップ保護により対処可能と考えますが、ミッションクリティカルなシステムの場合は留意が必要と思われます。 AWS上におけるファイル共有にて、Amazon FSx for OpenZFSがお手軽かつ有用であることが確認できた ので、良しとしましょう。 ここまでお読みいただきありがとうございました。

こんにちは、SCSK株式会社の中野です。 今年もZabbix Japanが主催するZabbix Conference Japan 2024が開催されます。 弊社も講演時間をいただき、本会場にて発表させていただきます。 本記事では少しだけ発表内容をお見せいたしますので、気になった方はぜひZabbix Conference Japan 2024までお越しください。 Zabbix Conference Japan 2024 概要 主催 Zabbix Jpan 日時 ＜本編前ウェビナー＞ 2024年11月18日（月）13:30～18:00 2024年11月19日（火）13:30～17:50 2024年11月20日（水）13:30～15:20         ＜本編＞ 2024年11月21日（木） 9:30～17:30 2024年11月22日（金） 9:30～17:00 会場 東京ポートシティ竹芝 ポートホール オンライン プログラム詳細とお申込みは、以下ページをご参照ください。 Zabbix Conference Japan 2024 SCSK発表内容について 講演ではZabbixへの移行のポイントや、Zabbix7.0のパフォーマンス限界調査、利用者様からよく届くお問い合わせ内容について発表させていただきます。 今Zabbixをお使いの方も、これからZabbixを使ってみようと考えている方も満足できる内容になっていると思いますので、ぜひご期待ください。 ＜本編前ウェビナー＞ タイトル 【Zabbixに乗り換え検討されてる方必見】Zabbix移行のすゝめ 日時 2024年11月19日（火）15:10～15:20 概要 オープンソースのシステム監視ツールであるZabbixの特徴と、他の監視ツールからZabbixへ乗り換える際に特に重要な４つのポイントについて、ご紹介します。この機会に、Zabbixへの移行を検討してみてはいかがですか？ ＜本編＞ タイトル ～限界シリーズ～　第2弾 Zabbix7.0のパフォーマンス限界調査編 日時 2024年11月21日（木）14:00～14:20 概要 Zabbix7.0LTSの新機能である、Pollerプロセスの並列処理実行について、どの程度処理性能向上に寄与しているのか、実際に試してみました。大人気「限界シリーズ」の第2弾です。   タイトル Zabbix Japan 公式サポートの最新動向 日時 2024年11月21日（木）15:20～15:50 概要 Zabbixに寄せられるサポート問い合わせについて、ディスカッション形式でお伝えさせていただきます。気になっていること、もしかするとその場で回答してしまうかもしれませんよ？リアルタイム視聴必須です。   最後に 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ x.com 以上、最後までご覧いただきありがとうございました。

こんにちは、2024年度入社の秋葉です！ クラウドやアプリ開発の現場でよく聞く「コンテナ技術」。 「結局何なの？」と疑問を持っている方も多いのではないでしょうか？コンテナは、アプリを軽く素早く動かせる仮想化技術で、開発・運用のスピードや効率を大きく向上させます。この記事では、私が新人研修を通して実際にコンテナ技術に触れて感じた魅力や使い方、初心者でも理解しやすいポイントを解説します。 これからコンテナを試してみたい方、ぜひ一緒に一歩踏み出してみましょう！ コンテナとは コンテナは、ホストOS上にアプリケーションの実行に必要な本体・ライブラリ・設定ファイルなどを一括管理し、「コンテナエンジン」を介して動かす技術です。分かりやすく例えると、PC内に仮想のミニPCを作ってアプリを動かすようなものと考えるとイメージしやすいでしょう。 従来の仮想化技術では、1つの仮想環境内にOSから必要な全ての要素を構築するため、異なるOSが求められるケースには便利でした。しかし、開発や運用の現場では「OSは共通で良い」という場合も多く、OSまで含めて用意するのはリソースの無駄になっていました。 その点、コンテナ技術では、 OS部分は共有 しつつ、アプリごとに必要なCPU・メモリ・ファイル・プロセス空間を独立した「コンテナ」として管理します。このため、軽量でかつ高速に起動することができどの環境でも同じように動作するのです。 仮想化と比較した際のメリット・デメリット メリット デメリット とにかく処理が軽量 環境構築に要する時間の大幅な削減 リリースサイクルの高速化に関わる「DevOps」と相性が良い 複数のホストでのコンテナ運用が煩雑になる 新しい技術であり学習コストが比較的高い コンテナ環境でベースとなるOSと異なるOSのシステムを動かすことはできない 各コンテナやコンテナサポートの特徴 Docker コンテナ技術を広く普及させたオープンソースのプラットフォームで、アプリケーションとその依存関係を単一のコンテナイメージにまとめ、異なる環境でも一貫性のある動作を提供します。 軽量で高速な起動 が特徴です。 Kubernetes コンテナ化されたアプリケーションをオーケストレーションするためのプラットフォームです。自動スケーリング、自己修復、および複雑なデプロイ戦略のサポートが可能です。 OpenShift Kubernetesをベースにしたエンタープライズ向けのコンテナプラットフォームで、Red Hatが提供しています。セキュリティ機能や開発者向けツールが統合されています。 Podman コンテナの運用と管理を行うためのオープンソースツールで、デーモンを必要としないアーキテクチャを採用しています。Docker CLIとの高い互換性があり、セキュリティリスクを低減するRootlessオペレーションをサポートしています。    Dockerとは Docker社が開発している、コンテナ型の仮想環境を作成、配布、実行するためのプラットフォームのことであり、コンテナのデファクトスタンダードとして広く使われている技術の1つです。 Dockerは、 Dockerイメージ と Dockerコンテナ という2つの主要な要素を使って動作します。 Dockerのメリット コード化されたファイルを共有することで、どこでも誰でも同じ環境が作れる。 作成した環境を配布しやすい。 スクラップ＆ビルドが容易にできる。 Dockerは、 軽量で迅速にデプロイ できるという利点から広く普及していますが、他のコンテナ技術と比較すると、用途や環境により異なる利点と欠点があります。 例えば、セキュリティ重視ならPodmanやrktが適しており、大規模オーケストレーションならKubernetesと組み合わせた利用が効果的です。目的に応じて技術を選定することで、効率的なシステム運用が実現できます。   Dockerイメージ作成からコンテナ起動までの流れ Dokcerイメージ作成 Dockerイメージは、 Dockerfile と呼ばれる設定ファイルから作成されます。Dockerfileには、イメージに含めるアプリケーションや依存関係、設定が記述されています。例えば、どのベースOSを使用するか、アプリケーションのインストール方法、環境変数の設定などが記載されます。（下記コードはDockerfileの例） FROM ubuntu:18.04 COPY . /app RUN cd /app CMD python /app/app.py Dockerfileが準備できたら、以下のコマンドを実行してDockerイメージを作成します。 $ docker build -t イメージ名:タグ Dockerfileのあるディレクトリ Dockerイメージの共有 作成したDockerイメージは、自分のローカル環境だけでなく、他の開発者やチームメンバーとも共有できます。一般的には、Dockerイメージの共有には Docker Hub というパブリックリポジトリが利用されます。Docker Hubは、他のユーザーがイメージをダウンロードできるプラットフォームです。（※研修ではECRへイメージを共有しました） Docker Hubのアカウントを作成し、ログインした後に以下のコマンドを実行することでイメージを共有します。 $ docker push ユーザー名/イメージ名:タグ Dockerコンテナの起動 以下のコマンドを使用することでDockerコンテナを起動します。 $ docker run [オプション] イメージ　[コマンド] [引数]   Dockerに触れてみた 初めてDockerとAWSのECRを使って、自分の作成したDockerイメージをクラウド上にデプロイしてみました！ ここでは、Dockerイメージの作成から、AWS ECRを利用してコンテナを起動するまでのステップを紹介します。 Dokcerイメージ作成 FROM amazoncorretto:17 COPY target/web-ui-teamG-0.0.1-SNAPSHOT.jar /web_app/ COPY src/main/resources/application-d0.yml /web_app/ WORKDIR /web_app ENTRYPOINT ["java", "-jar"] CMD ["-Dspring.profiles.active=local", "/web_app/web-ui-teamG-0.0.1-SNAPSHOT.jar"] 前節で紹介したコード例を参考に上記のようなDockerfileを作成しました。ベースイメージはDockerhubでなく、Amazon ECR Public Gallery のamazoncorretto を使用しています。 JARファイルを起動するように Dockerfile を記述し、下記コマンドでContainer ImageをBuildします。（※今回はtest） $ docker build -t test . Dockerイメージの共有 ECRへイメージをプッシュする前にAWS CLIコマンドを使用してECRにログインします。この際に、開発環境であるCloud9にAmazonEC2ContainerRegistryFullAccessなどのポリシーをアタッチしないとエラーになるので注意です！ $ sudo aws ecr get-login-password --region <your-region> | docker login --username AWS --password-stdin <your-account-id>.dkr.ecr.<your-region>.amazonaws.com ECRにログイン出来たら下記コマンドを実行してイメージをECRリポジトリ向けにタグ付けします。 $ docker tag <repository-name>:<tag> <your-account-id>.dkr.ecr.<your-region>.amazonaws.com/<repository-name>:<tag> タグ付けが完了したら下記コマンドを実行してECRへイメージをプッシュします。 $ docker push <your-account-id>.dkr.ecr.<your-region>.amazonaws.com/<repository-name>:<tag> Dockerコンテナの起動 最後に前節のコンテナ起動のコマンドを実行してコンテナを起動できたら終了となります。 コンテナが起動したら下写真のようにDockerファイル内で指定しているjavaアプリケーションが実行されます。   終わりに ～Dockerに触れてみた感想～ Dockerを使用した最初の印象は、「シンプルで強力なツール」というものでした。コンテナ技術により、アプリケーションの設定や依存関係が一つのイメージにまとめられ、どの環境でも同じように動作することに驚きました。 初めて触れる際には学びのハードルも感じるかもしれませんが、その魅力を理解し、実際に触れてみることで多くの可能性を感じることができましたので今後もコンテナについて学び続けたいと思います！！

初めまして。 SCSKの多田といいます。 今まではAWSでサーバレス環境の構築等を行うことが多かったのですが、今期よりEC2を使ったサービスを提供している部署に異動となり、最初の仕事としてEC2の運用周りを見直す機会に携わりました。 その中で、サービス提供中のEC2のバックアップとしてAMI作成を手動で作成しているのを人手を介さずに自動化できないかなーとお題をいただいたので、EC2周りの勉強がてら実施してみることにしました。 最初は「EC2のマネジメントコンソールのアクションボタンからイメージ作成を選択するのを自動化するだけの簡単なお仕事」と思っていたのですが、思いのほか、はまったり、悩んだりといったことがありましたので、皆さんに共有できればと思い記事にしてみました。 なお、簡単な(当初は)お仕事の概要としては以下のポイントとなります。 運用中のEC2からゴールデンイメージ(AMI)を作成 ゴールデンイメージにはEC2のログやテンポラリのファイルなどを含めないようにしたい 完全自動化(上記のEC2内部のクリーンアップや作成したイメージの管理まで) 構成について   利用した主なAWSサービス 今回、利用した主なAWSのサービスは以下の2つとなります。 EC2 Image Builder Image Builder とは - EC2 Image Builder Image Builder は、安全なカスタム Amazon マシンイメージ (AMIs) またはコンテナイメージを作成し、 内の送信先アカウントとリージョンで使用できるように配布するために使用できるフルマネージドサービスです AWS。 docs.aws.amazon.com Systems Manager Automation AWS Systems Manager Automation - AWS Systems Manager Systems Manager Automation により、Amazon EC2 インスタンスおよびその他の AWS リソースの一般的なメンテナンスとデプロイを簡素化します。 docs.aws.amazon.com 全体の構成について いきなりですが、今回の機能の全体の構成図は以下の通りとなります。 図1 全体イメージ図 まず、このSystems Manager AutomationとEC2 Image Builderの2つを組み合わせた構成になった背景について説明します。 EC2 Image Builder自体はAMI(図1 ①)を起点にして最終的なAMI(図1 ⑨)を作成するサービス となります。 そのため、稼働中のEC2から最終的なAMIを作成するためには、EC2 Image Builderだけでは実現できなく、 Systems Manager Automationを使って起点となる一時的なAMI(図1 ①)を作成 しています。 その後、EC2 Image Builderの設定、起動(図1 ②～⑦)などもSystems Manager Automationを使って実行しています。 そして最後に一時的に作成したAMIは不要なものになるため、最後に削除(図1 ⑧)しています。 AWS Systems Manager Automationの構成について 次にSystems Manager AutomationとEC2 Imager Builderの詳細について説明していきます。 まず、実際に検証で使用したSystems Manager Automationの構成は以下の通りとなります。 図2 Systems Manager Automationの構成図 Systems Manager Automation内のワークフローの詳細は以下の表の通りとなります。 表1 Systems Manager Automationのステップ一覧 項番 アクション Service API 概要 1 aws:createImage – – EC2から一時的なAMIを作成 2 aws:executeAwsApi imagebuilder CreateImageRecipe EC2 Image Builderのレシピを作成 3 aws:executeAwsApi imagebuilder UpdateImagePipeline EC2 Image Builderのパイプラインを更新 (項番2で作成したレシピをパイプラインに組み込む) 4 aws:executeAwsApi imagebuilder StartImagePipelineExecution EC2 Image Builderのパイプラインを起動 5 aws:waitForAwsResourceProperty – – AMIが作成されるまで待つ 6 aws:executeAwsApi imagebuilder TagResource 作成されたAMIにタグを付与 7 aws:executeAwsApi imagebuilder UpdateImagePipeline EC2 Image Builderのパイプラインを更新 (項番3で組み込んだレシピをパイプラインから取り外す) 8 aws:executeAwsApi imagebuilder DeleteImageRecipe EC2 Image Builderのレシピを削除 (項番7で取り外したレシピを削除する) 9 aws:deleteImage – – 項番1で作成した一時的なAMIを削除 実際の定義は以下になります。なお、各パラメータ等はご要件に併せて変更していただくようお願いします。 schemaVersion: '0.3' assumeRole: arn:aws:iam::XXXXXXXXXXXX:role/XXXXXXXXXX mainSteps: - name: CreateAMI action: aws:createImage nextStep: CreateImageRecipe isEnd: false inputs: ImageName: XXXXXXXXXX NoReboot: true InstanceId: XXXXXXXXXX - name: CreateImageRecipe action: aws:executeAwsApi nextStep: UpdateImagePipeline isEnd: false inputs: Service: imagebuilder Api: CreateImageRecipe parentImage: '{{ CreateAMI.ImageId }}' components: - componentArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:component/XXXXXXXXXX/1.0.0/1 semanticVersion: 2.0.0 name: XXXXXXXXXX outputs: - Type: String Name: ImageRecipeArn Selector: $.imageRecipeArn - name: UpdateImagePipeline action: aws:executeAwsApi nextStep: StartImagePipelineExecution isEnd: false inputs: Service: imagebuilder Api: UpdateImagePipeline imageRecipeArn: '{{ CreateImageRecipe.ImageRecipeArn }}' distributionConfigurationArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:distribution-configuration/XXXXXXXXXX workflows: - workflowArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:workflow/build/XXXXXXXXXX/1.0.0/1 executionRole: arn:aws:iam::XXXXXXXXXXXX:role/XXXXXXXXXX imagePipelineArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:image-pipeline/XXXXXXXXXX infrastructureConfigurationArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:infrastructure-configuration/XXXXXXXXXX - name: StartImagePipelineExecution action: aws:executeAwsApi nextStep: WaitOnAWSResourceProperty isEnd: false inputs: Service: imagebuilder Api: StartImagePipelineExecution imagePipelineArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:image-pipeline/XXXXXXXXXX outputs: - Type: String Name: ImageBuildVersionArn Selector: $.imageBuildVersionArn - name: WaitOnAWSResourceProperty action: aws:waitForAwsResourceProperty timeoutSeconds: 3600 nextStep: TagResource isEnd: false inputs: Service: imagebuilder Api: GetImage PropertySelector: $.image.state.status DesiredValues: - AVAILABLE imageBuildVersionArn: '{{ StartImagePipelineExecution.ImageBuildVersionArn }}' - name: TagResource action: aws:executeAwsApi nextStep: UpdateImagePipeline_default isEnd: false inputs: Service: imagebuilder Api: TagResource tags: AMIType: XXXXXXXXXX resourceArn: '{{ StartImagePipelineExecution.ImageBuildVersionArn }}' - name: UpdateImagePipeline_default action: aws:executeAwsApi nextStep: DeleteImageRecipe isEnd: false inputs: Service: imagebuilder Api: UpdateImagePipeline imageRecipeArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:image-recipe/default/1.0.0 distributionConfigurationArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:distribution-configuration/XXXXXXXXXX imagePipelineArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:image-pipeline/XXXXXXXXXX infrastructureConfigurationArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:infrastructure-configuration/XXXXXXXXXX - name: DeleteImageRecipe action: aws:executeAwsApi nextStep: DeleteAMI isEnd: false inputs: Service: imagebuilder Api: DeleteImageRecipe imageRecipeArn: '{{ CreateImageRecipe.ImageRecipeArn }}' - name: DeleteAMI action: aws:deleteImage isEnd: true inputs: ImageId: '{{ CreateAMI.ImageId }}' Step Functionsを利用したことがあると、ステップ間の情報の渡し方、情報の参照のや方法はイメージしやすいかも。   Systems Manager Automation構成のポイントについては、QA方式でまとめてみます。 表1の項番2 なぜ、実行するたびにイメージレシピを作成しなおしているの？ イメージレシピを作成する際には、元になるAMIのIDを指定する必要があります。 今回のようにSystems ManagerのAutomationを実行するたびに起動中のEC2からAMIを作成している場合には、AMI IDが毎回異なるため、イメージレシピを作成(もしくは更新)してあげる必要があります。                                       では、何故、毎回イメージレシピを新規作成にしているかというと、 イメージレシピを更新する場合はイメージレシピのバージョンを変更しなければならなく、例えば1.0.0→1.0.1のように既存のものとは異なるバージョンにする必要がありますが、 バージョン番号を実行するたびに動的に生成したくなかったというのが理由になります。 動的というのは例えばですがバージョン番号を既存のイメージレシピから取得してインクリメントした値を返すようなLambdaの作成が想定されますが、今回はなるべくコード作成などは行わずにしたかったため、バージョンは固定(2.0.0)として作成して、利用が終わったらイメージレシピを表1の項番 8で削除するようにしています。    イメージレシピの新しいバージョンを作成する - EC2 Image Builder Image Builder イメージレシピの新しいバージョンを作成します。 docs.aws.amazon.com   表1の項番5   どうして、AMIが作成されるまで待つ必要があるの？ これは表1の項番4で実行されている 「StartImagePipelineExecution」が非同期のAPI となっているためです。 その後の表1の項番7で作成されたイメージレシピを削除するためにイメージパイプラインから切り離すようにしているのですが、イメージパイプラインが実行中だと切り離しができません。 そのため、イメージが作成されてイメージパイプラインが実行されてない状態になるまで待つようにしています。     表1の項番6   何のためにイメージにタグを付与しているんだろう？ 目的としては作成されたイメージに対してライフサイクルポリシーを適用するためです。 今回のように自動的にAMIを作成していくとどんどんイメージがたまっていくため、保存していくイメージ数を管理していく必要がでてきます。 EC2のImage Builderにはイメージのライフサイクルを設定できるライフサイクルポリシーという機能がありますが、その中で ポリシーの適用の対象をタグで指定するようにしているため です。 ここでのタグはEC2のImage Builderでのイメージに付与されるタグになります。AMIのタグとは別のものになりますのでご注意ください。 ライフサイクルポリシーの作成 - EC2 Image Builder EC2 Image Builder ライフサイクル管理ポリシーを作成します。 docs.aws.amazon.com   Amazon EC2 Image Builder の構成について Image Builder の構成のポイントとなる機能について説明します。 イメージパイプライン 最初にイメージパイプラインについて説明します。 AMI イメージパイプラインの作成と更新 - EC2 Image Builder Image Builder AMIイメージパイプラインを作成および更新します。 docs.aws.amazon.com 「イメージパイプラインの作成」ボタンを押下して作成しますが、今回の目的におけるポイントは次の3つになります。 「ビルドスケジュール」の選択について                            図3 EC2 Image Builder設定例-1 「ビルドスケジュール」については、 今回はSystems ManagerのAutomationからEC2のImage Builderを実行することになる ため、「手動」で設定します。 また、Systems ManagerのAutomationを定期的に自動で実行したい場合には、別途EventBridgeでスケジュール設定を行います。 「レシピの詳細」の選択について                             図4 EC2 Image Builder設定例-2 Systems ManagerのAutomationの箇所でも触れましたが実際に使用されるイメージレシピは表1の項番2で作成された後、項番3でイメージパイプラインに設定、項番7でイメージパイプラインから取り外されます。 そのためここの「レシピの詳細」で設定されるレシピは項番8から項番2までの状態のイメージパイプラインに設定されているイメージレシピとなります。 なお、このイメージレシピは実行されることのないものになりますので、今回は「Amazon管理」で提供されている適当なコンポーネントを選んで作成したイメージレシピを選択するようにしています。 上記の図4では、事前に「Default」という名前のレシピを作成済みのため、それを選択しています。 「タイプ」で選択するワークフローの選択について                                   図5 EC2 Image Builder設定例-3 今回は図5のようにオリジナルのイメージワークフローの「CreateAMI-WorkFlow」を設定しています。 詳細については次の「イメージワークフロー」にて説明します。 イメージワークフロー 「タイプ」で選択するワークフローについて説明します。 Image Builder でイメージパイプラインワークフローを設定する - EC2 Image Builder Image Builder パイプラインのイメージワークフローを設定します。 docs.aws.amazon.com 簡単に言うと、EC2 Image BuilderでAMIを作成する際の手順が定義されたものになります。 参考までにAWSが提供しているbuild-imageのイメージワークフローの内容を以下に貼付します。 name: build-image description: Workflow to build an AMI schemaVersion: 1.0 steps: - name: LaunchBuildInstance action: LaunchInstance onFailure: Abort inputs: waitFor: "ssmAgent" - name: ApplyBuildComponents action: ExecuteComponents onFailure: Abort inputs: instanceId.$: "$.stepOutputs.LaunchBuildInstance.instanceId" - name: InventoryCollection action: CollectImageMetadata onFailure: Abort if: and: - stringEquals: "AMI" value: "$.imagebuilder.imageType" - booleanEquals: true value: "$.imagebuilder.collectImageMetadata" inputs: instanceId.$: "$.stepOutputs.LaunchBuildInstance.instanceId" - name: RunSanitizeScript action: SanitizeInstance onFailure: Abort if: and: - stringEquals: "AMI" value: "$.imagebuilder.imageType" - not: stringEquals: "Windows" value: "$.imagebuilder.platform" inputs: instanceId.$: "$.stepOutputs.LaunchBuildInstance.instanceId" - name: RunSysPrepScript action: RunSysPrep onFailure: Abort if: and: - stringEquals: "AMI" value: "$.imagebuilder.imageType" - stringEquals: "Windows" value: "$.imagebuilder.platform" inputs: instanceId.$: "$.stepOutputs.LaunchBuildInstance.instanceId" - name: CreateOutputAMI action: CreateImage onFailure: Abort if: stringEquals: "AMI" value: "$.imagebuilder.imageType" inputs: instanceId.$: "$.stepOutputs.LaunchBuildInstance.instanceId" - name: TerminateBuildInstance action: TerminateInstance onFailure: Continue inputs: instanceId.$: "$.stepOutputs.LaunchBuildInstance.instanceId" outputs: - name: "ImageId" value: "$.stepOutputs.CreateOutputAMI.imageId" 内容をご覧いただくと分かりますが、上の方でも記載しているSystems ManagerのAutomationの定義のようなフローが記述された設定となっています。 ちなみにこの中で実際に行われている処理の内容は以下のリンクに記載があります。 ワークフロードキュメントでサポートされているステップアクション - EC2 Image Builder Image Builder YAML ワークフロードキュメントの でサポートされているステップアクションを使用します。 docs.aws.amazon.com 上記の処理の内容については一通り把握しておくことをお勧めします。 特に「SanitizeInstance」の処理は、AWSが想定しているインスタンスのサニタイズ処理がされるため、作成するイメージとして問題がないかは確認をしたほうがよいです。 もし、イメージワークフローで実施してほしくない処理などがあれば、既存のものを参考にして「イメージワークフローを作成」ボタンから作成して、イメージパイプラインに組み込むことが可能です。 今回は「SanitaizeInstance」の処理の一部が不要なものであったので、オリジナルのイメージワークフロー「CreateAMI-WorkFlow」を作成しています。   コンポーネント 最後にコンポーネントについて説明します。 コンポーネントを使用して Image Builder イメージをカスタマイズする - EC2 Image Builder コンポーネントを使用して EC2 Image Builder イメージをカスタマイズします。 docs.aws.amazon.com 今回はインスタンスに対して独自の処理(ログファイルや一時作成のファイルの削除など)を行いたかったため、独自のコンポーネントを作成しています。 作成にあたっては以下のリンクを参考にしました。 Image Builder イメージのカスタムコンポーネントを開発する - EC2 Image Builder Image Builder イメージのカスタムコンポーネントを開発する docs.aws.amazon.com Use the AWSTOE component document framework for custom components - EC2 Image Builder Use YAML component documents with AWS Task Orchestrator and Executor component document framework to create custom compo... docs.aws.amazon.com なお、イメージレシピにはこのコンポーネントを組み込む形になります。(上記のSystems ManagerのAutomation定義の一部抜粋) - name: CreateImageRecipe action: aws:executeAwsApi nextStep: UpdateImagePipeline isEnd: false inputs: Service: imagebuilder Api: CreateImageRecipe parentImage: '{{ CreateAMI.ImageId }}' components: - componentArn: arn:aws:imagebuilder:ap-northeast-1:XXXXXXXXXXXX:component/XXXXX/1.0.0/1 semanticVersion: 2.0.0 name: XXXXXX outputs: - Type: String Name: ImageRecipeArn Selector: $.imageRecipeArn   以上で、設定に悩んだ、もしくははまった個所については触れることができました。 上記以外の機能(インフラストラクチャ設定、ディストリビューション設定、ライフサイクルポリシー)については、大きく悩む箇所はなかったため割愛させていただきます。   最後に   以上、ざっとですが今回のお題をクリアするための構成ができたことになります。 最後までお読みいただき、ありがとうございました。 最初の想定に比べると倍以上は複雑になってしまったのと、加えてSystems ManagerのAutomationでのパラメータ設定などはドキュメントから読み取れないことも多くトライ&エラーの連続でした。 今回の設定が同じようなことを試そうとしている方に少しでもお役に立てればと思います。

こんにちは、2024年度入社の齋藤です。 現在私は、フルスタック人材の育成を目的とした新人研修に取り組んでいます。Webアプリケーションの開発からAWSを用いたインフラ構築まで幅広い知識を習得できるため、非常に充実した研修内容だと感じています。 今回は、その一環としてAWS Cloud9上でWebアプリケーションの開発を行った際に用いた、 Spring Boot というフレームワークを紹介します。 Spring Boot の概要 まず、Spring Boot の概要について説明します。 Spring Boot とは Spring Boot とは、JavaでのWebアプリケーション開発を迅速かつ効率的に行うための フレームワーク です。 Spring Frameworkに搭載されているフレームワークの1つで、手軽な設定と少ないコード量でアプリケーションを作成するのに役立ちます。 Spring Boot の特徴 ①Webコンテナの内包 Spring Boot は、Webアプリケーション開発を容易にするために、WebコンテナをJAR(JavaARchive)ファイルに内包することができます。これにより、単一のJARファイルでWebアプリケーションを作成し、 手軽にデプロイ することが可能です。デフォルトでTomcatコンテナが含まれていますが、必要に応じて他のコンテナに切り替えることもできます。 ②DI(依存性の注入)   依存しているとは？ 「依存している」とは、「クラスAを正しく動作させるためには、クラスBが必要である」という状態を指します。これは、クラスAがクラスBに依存してることを意味しており、この状態ではクラスAが利用する機能をテストする際にも、クラスBが完成している必要があります。 通常、下の図のようにクラスAがクラスBを直接呼び出す場合、強い依存関係が発生します。 DI(Dependency Injection)を利用することで、クラスAはインターフェースを通じてクラスBを使用します。これにより、クラスBに依存せず、クラスAの単体テストを実行することが可能です。 Spring Boot では、 アノテーション を使用することで、 依存関係のあるインスタンスの管理を自動化 します。これにより、インターフェイスを介すことなく依存関係を保つことができ、コードの可読性と保守性が向上し、開発効率が向上します。 これらの特徴を活かすことで、Spring Boot はJavaによるWebアプリケーション開発をより効率的かつ容易に行うことができる協力なツールとなっています。   開発環境 AWS Cloud9 での Spring Boot のアプリケーション開発方法について説明します。 実施方法 Spring Boot のプロジェクトの作成 Cloud9の画面下部のTerminalで下記コマンドを入力 spring init -j=17 --build=maven -d=web,thymeleaf -g=jp.scsk --package-name=jp.scsk.training.trgapp -a=web-ui-team-developer -n=web-ui-team-developer web-ui-team-developer 実行された結果、web-ui-team-developerの Spring Boot のプロジェクトが作成されたことを確認する。 アプリケーションの実行 Cloud9の画面中央上部にある「Run」ボタンをクリックしてアプリケーションを実行します。 画面下部のターミナルにアプリケーションのログが表示されることを確認します。 実行結果 Using service at https: //start .spring.io Project extracted to  '/home/ec2-user/environment/web-ui-team-developer' ディレクトリ構造 Spring Boot プロジェクトを作成すると、以下のディレクトリ構造が作成されます。この構造は、プロジェクトを整理し、コードの管理を容易にするために設計されています。 web-ui-team-developer/ └── src/ ├── main/ │ ├── java/ │ │ └── jp/scsk/training/trgapp │ │ ├── Application.java │ │ ├── controller/ │ │ ├── service/ │ │ └── repository/ │ └── resources/ │ ├── application.properties │ ├── static/ │ └── templates/ └── test/ └── java/ └── jp/scsk/training/trgapp   Spring Boot を使ってWebアプリケーション開発に挑戦 Spring Boot を使ってWebアプリケーション開発に挑戦してみました。Webアプリケーション開発は設定ファイルの記述量が多く、敷居が高く感じていました。しかし、Spring Boot は設定ファイルが自動生成され、アノテーションで簡単に機能を追加できるため、非常に快適な開発体験でした！ とはいえ、初めての Spring Boot 開発で、いくつか戸惑ったポイントもありました。今回は、その中でも特に難しかったと感じた2つのポイントを紹介します。 アノテーションの付与 Spring Boot は、 アノテーション と呼ばれるメタデータを使って、さまざまな機能を追加できます。アノテーションは、コードに特別な意味を付与し、Spring Boot にどのように動作させるかを指示する役割を果たします。 しかし、アノテーションの種類が多く、どのアノテーションをどの場所に付与すればいいのか、最初は戸惑いました。特に、複数のアノテーションを組み合わせる場合、その動作を理解するのに苦労しました。 Spring Boot のアノテーションについて、実際に作成したコントローラークラスを用いて紹介します。 @Controller 、 @GetMapping 、 @Autowired などのよく使うアノテーションの用途と使い方を理解することで、Spring Boot アプリケーションをよりスムーズに開発できるようになります。 @Controller このクラスがコントローラークラスであることを示します。つまり、Webリクエストを受け取って処理を行う役割を担うクラスであることを宣言しています。 @GetMapping HTTP GETリクエストを処理するメソッドを定義します。 @Autowired Springの依存性注入機能を利用して、Serviceクラスに自動的に連携させます。   pom.xmlファイルの修正 Spring Boot プロジェクトを作成しただけでは、Webアプリケーションをビルドして実行することができませんでした。 pom.xmlファイル に、ビルド設定を追加する必要がありました。 pomファイルとは？ pomファイルは、 プロジェクトの構成と依存関係を管理する ための重要な設定ファイルです。pomファイルには、プロジェクトのビルド、パッケージング、実行に必要な情報が記述されており、開発者はこのファイルを使用してプロジェクトを効率的に管理できます。 具体的には、以下の2つのプラグインを追加しました。 maven-jar-plugin： Javaソースコードをコンパイルするためのプラグイン maven-compiler-plugin： Javaソースコードをコンパイルして生成されたクラスファイルをjarファイルにパッケージングするためのプラグイン この修正で、Spring Boot アプリケーションが適切にパッケージングされ、実行時に起動クラスが正しく呼び出されるようになりました。 ただ、pom.xmlファイルは、プロジェクトの構成情報全体を定義するため、変更する際は慎重に進める必要があります。特に、プラグインのバージョンや依存関係のバージョンを間違えると、ビルドエラーが発生したり、アプリケーションが正常に動作しなくなる可能性がありますのでご注意を。。   おわりに 本投稿では、Spring Boot の基本的な機能や特徴や触ってみた感想について書いてみました。JavaによるWebアプリケーション開発を効率的に進めるための役立つツールであることを理解いただけたでしょうか。Spring Boot を利用することで、迅速な開発と保守性の高いコードの実現が可能となります。ぜひ Spring Boot を開発に活かしていただければと思います。

GCPのCloud Data Fusionはデータパイプラインを作成、管理できるサービスです。Data FusionとCloud Pub/Subを組み合わせることで、日々発生するデータをリアルタイムにDWHへ格納することができます。 今回はデータをリアルタイムにDWHへ連携するパイプラインを、Cloud Data Fusion上に構築してみたいと思います。 作成方法と作成時のポイントを記載します。 使用するサービスの概要 Cloud Pub/Sub アプリケーションとデータ統合用の Pub/Sub | Google Cloud Pub/Subは非同期メッセージサービスです。 リアルタイムデータはスマホやIoT機器などから生成されますが、Cloud Pub/Subを中継するように設計することで、 より便利によりセキュアになります。 また、GCPのリソースと連携がしやすく、フルマネージドサービスのため簡単に作成ができます。 今回はPub/Subにデータ発生元からデータが連携された想定でパイプラインの構築と検証を行います。 BigQuery BigQuery エンタープライズ向けデータ ウェアハウス | Google Cloud BigQueryはフルマネージドのデータウェアハウスサービスです。 今回はこのBigQueryにデータを格納できることをゴールとします。 Cloud Data Fusion Cloud Data Fusion | Google Cloud Data Fusionはコードを意識せずにデータパイプラインを作成、管理できるフルマネージドサービスです。 作成できるパイプラインは、実行するごとに処理が流れる バッチパイプライン と、パイプラインを実行し続けトリガーがあった際に都度処理が走る リアルタイムパイプライン の2種類あります。 今回はリアルタイムパイプラインを使用して構築していきます。   なお、バッチパイプラインの作成方法については、下記の記事をご確認ください。 下記の記事ではGCS上のファイルからデータを連携する方法が記載されています。 【GCP】Cloud FunctionsのCloud StorageトリガーでDataFusionパイプラインを起動 – TechHarmony   実際に作ってみる 実現したい事 今回実現したいことは下記です。 ゴール Cloud Pub/Subに投入したデータがBigQueryに格納される フロー Cloud Pub/Subにて「1111 aaaa」という文字列を公開する Pub/Subでデータが公開されたら、DataFusionリアルタイムパイプラインにてPub/Subからデータを受け取り、データを修正した後BigQueryに格納する BigQueryにて「1111」と「aaaa」が異なるカラムに入る IAMの設定 まず、本検証を実行するのにあたって必要な権限を各サービスアカウントに付与します。 GCPのIAMのページを開き、画面右上にある「Include Google-provided role grants」にチェックを入れます。 「Cloud Data Fusion Service Account」に「Pub/Sub編集者」のロールを付与します。 Cloud Pub/Sub作成 GCPのPub/Subページからトピックを作成します。 「デフォルトのサブスクリプションを追加する」にチェックを入れると自答的にサブスクリプションが作成されます。 トピック：userlist サブスクリプション：userlist-sub（自動で作成） BigQuery作成 GCPのBigQueryページから以下のネーミングにてデータセットとテーブルを作成します。 データセット：user テーブル：list スキーマ：id、name パイプライン構築 Data Fusionインスタンス作成 Data Fusionインスタンスが作成されていない場合は、まずはGCPのData Fusionページからインスタンスを作成します。 作成時のポイントとして、「認可」項目に以下の警告が出た場合は「権限を付与」ボタンをクリックしないと後続のパイプラインを実行する際にエラーがでたため、許可を押しています。 また、インスタンスの作成には数十分時間がかかるので注意が必要です。   リアルタイムパイプライン作成 インスタンスが作成されたら、インスタンス一覧の「インスタンスを表示」を押します。 以下の画面になるので、「List」を押します。 画面右上の+マークから「CREATE」を押します。 パイプラインの作成画面が出るので、左上部にある「Data Pipeline – Batch」を「Data Pipeline – Realtime」に変更します。 画面上部の赤枠の部分から、名前を任意の値に変更します。（今回は「Realtime-userlist」と命名） ここから先は、各プラグインを選択していきます。   Source：Pub/Sub Sourceでは、データの投入元情報を設定します。 今回はデータ投入元はPub/Subのため、左側の「Source」項目から「Pub/Sub」をクリックします。 表示されたPub/Subプラグインにマウスカーソルを合わせると、「Properties」ボタンが表示されるのでクリックします。 表示された画面で、以下の情報を入力します。 Reference Name：pubsub Subscription：userlist-sub Topic：userlist これでSourceの設定は完了です。 入力後、右上の×マークをクリックし、元の画面に戻ります。   Transform：Wrangler 次に入ってきたデータを変換するTransformの設定を行います。 「Transform」から「Wrangler」を選択します。 表示されたら「Pub/Sub」から矢印を引っ張ります。 WranglerのPropertiesの中身は以下にて設定します。 Recipe： keep :message set-type :message string split-to-columns :message \s+ drop :message rename message_1 id rename message_2 name Output Scema：id (string)、name (string)　に設定し、チェックボックスにチェックを入れる   Recipeではデータを変換する処理を記述しています。 詳細な作成方法は割愛しますが、Pub/Subから連携されるデータは、JSON形式のmessageキーの値として引き渡されるため、受け取った値をBigQueryのスキーマに合わせて「id」と「name」に分割しています。 Output Scemaでは次のプラグインに引き渡すスキーマ情報を設定しています。   Sink：BigQuery 最後にデータを別リソースに引き渡すSinkを設定します。 今回はBigQueryにデータを投入したいため、「Sink」から「BigQuery」を選択します。 表示されたら「Wrangler」から矢印を引っ張ります。 BigQueryのPropertiesの中身は以下にて設定します。 Use connection：YES Connection：（BROUSE CONNECTIONSをクリックして選択）BigQuery Default Reference Name：bigquery Dataset：user Table：list また、画面最下部にある「Output Scema」がWranglerと同様に「id」「name」と設定されていることを確認します。（されていなければWrangler同様に設定します）   Configure設定 Sinkの設定まで終わったら、パイプライン画面上部の「Configure」をクリックします。 「Pipeline config」の「Batch Interval」を60秒に変更（デフォルトは10秒）後、Saveします。   パイプラインのデプロイ、実行 画面上部の「Save」ボタンをクリックします。 Saveが完了したら、隣の「Deploy」ボタンをクリックします。 編集画面から遷移したら、デプロイ完了です。 ※注意点 リアルタイムパイプラインは、一度デプロイしたパイプラインは編集ができません。 そのため、設定値などを修正したい場合はコピーして新たに作り直し、再度デプロイする必要があります。（バッチパイプラインはデプロイ後も編集が可能です）   パイプラインを実行、データを投入してみる デプロイしたパイプラインを実行します。 画面上部の「Run」ボタンをクリックします。 ※実際に実行してみると、パイプラインが起動してデータをリアルタイムに受け付けるまではおよそ8分程度かかりました。   起動から8分程度経過し、「Status」が「Running」となっていたら、データ投入を開始します。 作成したPub/Subトピック内メッセージタブから「メッセージをパブリッシュ」をクリックします。 メッセージ本文に「1111 aaaa」と入力、「公開」ボタンをクリックします。 作成したBigQueryテーブルのプレビュータブに以下の通りにデータが格納されました！ パイプラインを見に行くと、各プラグインのIn/Outに流れたデータの数が表示されていました。   作成時の注意点 パイプライン構築にあたって、個人的に引っかかったポイントや注意点を以下に記載します。 権限周り インスタンス作成時に、Data FusionにDataprocサービスアカウントへの権限を付与しないと、パイプライン実行がエラーとなりました。また、IAM周りも適切に設定してあげないとリソース間でうまくデータが流れないようです。 各環境と使用リソースに合わせて設定する必要があります。   リアルタイムパイプラインはデプロイ後修正ができない 修正ができないので、都度値を変更して検証するには時間がかかりました。パイプライン内歯車マークから「Duplicate」をクリックするとパイプラインのコピーが出来上がるので、この方法で修正⇒再デプロイを実施する形となります。   Batch Intervalを10秒から60秒に変更しないとパイプラインがうまく動かない 本記事内「Configure設定」にて記載しましたが、Batch Intervalを変更しなければ本パイプラインはうまく処理が進みませんでした。 Configure設定 Sinkの設定まで終わったら、パイプライン画面上部の「Configure」をクリックします。 「Pipeline config」の「Batch Interval」を60秒に変更（デフォルトは10秒）後、Saveします。 Batch IntervalはBigQueryへの書き込み時間の間隔となりますが、デフォルトの10秒だと書き込みの間隔が短く過剰アクセスが発生していると考えられ、GCPサポートからはBatch Intervalを60秒以上に設定して検証するように推奨されました。 また、本項目を変更するのは デプロイ前 である必要があります。パイプラインデプロイ後は、画面上はBatch Intervalの変更をすることができますが、実際には設定が反映されずエラーとなってしまいました。 GCPサポートに問い合わせたところ、 リアルタイムパイプラインの内容は途中で編集ができず再作成と再デプロイが必要であり、エンジン側のパラメータ設定などについても再作成と再デプロイによって反映させる必要がある。 とのことで回答がありました。 なお、デプロイ後に同項目を編集してしまった場合は、実際に設定されている値と画面上の値の乖離が起きてしまいますが、実際に設定されている値については、パイプラインを実行した際のログ内以下項目にて確認ができます。 「 – INFO〜 Remember interval = 〜 ms」   Data Fusionのコスト Data Fusionは作成したインスタンスごとに課金がされるため、インスタンスを複数作成するとその分コストがかかります。 また、Data Fusionのインスタンスは停止再開ができないため、 一度作成したら削除するまで 課金され続ける点に注意が必要です。 インスタンスを削除すると作成していたパイプラインも同時に削除されてしまうため、インスタンスを削除する場合はパイプラインをJSON形式でエクスポートなどしておくと良いかもしれません。 詳しい料金は公式の料金ページをご確認ください。 料金  |  Cloud Data Fusion  |  Google Cloud   最後に 今回はPub/SubをトリガーとしたData Fusionのリアルタイムパイプラインを構築してみました。 今回作成したパイプラインを使用すれば、発生したデータをCloud Pub/Subに向けて流すように設定するだけで、リアルタイムにBigQueryにデータを格納することができ、データ活用に役立ちそうですね。 今回の構築で初めてGCPを触ったのですが、Data Fusionはコードを書かずにパイプラインを構築できるため非常に扱いやすかったです。 ただGCPの権限周りについては、サービスアカウントに権限を追加しないと他リソースとの連携ができない場面があり、リソース作成時には都度勉強が必要だと思いました。 皆さんもData Fusion使ってみてはいかがでしょうか。

こんにちは。2024新人の加藤です。 今回はAWS上のCloudFormationと構成管理ツールのAnsibleを使用し、その便利さに感銘を受けたため、具体的に何を行って、どのような部分に感銘を受けたかご紹介したいと思います。 Ansibleとは Ansibleとは、RedHat社が開発するシステム設定やソフトウェアの自動化を行う構成管理ツールです。 Ansibleにはコントロールノードと管理対象ノードが存在します。 コントロールノードに管理対象ノードのあるべき状態を記載した「Playbook」ファイルを作成し、「Inventory」ファイルに管理対象ノードの情報を記載します。「Inventory」と「Playbook」の内容は以下のようになっています。 Inventory リモートホストやグループを管理するファイル ファイル名は「hosts」 Playbook リモートホストの状態を定義するymlファイル Inventoryで管理されたグループやホスト単位で作成 ファイル名は「main.yml」 今回は、Ansibleを各EC2のUserDataでlocalhost実行するため、コントロールノードと管理対象ノードが同じになります。 また、Playbookファイルは「ロール」形式を取ることによって、効率的にファイル管理をすることができるようになります。ロールとは、Playbookファイルを複数に分割し、別のファイルとして実行・管理できる仕組みのことです。   構成概要 アプリケーションをEC2上にホストし、プライベートネットワーク環境のPCからそのEC2にアクセスしWebページが表示されるか確認します。EC2へのアプリケーションのホストは構成管理ツール（Ansible）を使用し、自動化します。 EC2にアクセスする際にはパブリックサブネットに配置したELBを経由してアクセスするものとし、HTTPSプロトコルを使用してアクセスします。   AWS CloudFormationで各リソースをIaC化し、ルートテンプレートから複数スタックを作成しています。 スタック構造は以下のようになっています。 Application_Stack：親スタック Network_Stack：ネットワークリソースを作成する子スタック（Subnet、Route） Application_quickstart_Stack：アプリケーション実行に必要なリソースを作成する子スタック（IAM、SecurityGroup、Route53、ACM、ELB、EC2） 各リソースの詳細内容 各リソースの詳細内容は以下のようになっています。 No. カテゴリ 項目 詳細 備考 1 アプリケーション Spring Boot WebアプリケーションはSpring Bootを使用して作成する ページ概要は以下の通りである 「検証用APトップページ」ボタンを実装する 「一覧」ボタンを実装する 「dummy」ボタンを実装する   2 Ansible Playbook 以下のAnsible構成図を基に作成する 各ロールの役割を記載する linux_common_config： yumリポジトリのアップデート（yumでインストールされたすべてのパッケージのアップデート） web_ui_config： Amazon Corretoのインストール S3からJarファイル取得 Jar起動 今回はAnsibleをローカルホストから実行するためは、インベントリファイルは作成しない 3 AWS IAM 以下の権限を付与する S3へのアクセス（ReadOnly） SystemsManagerへのアクセス（AmazonSSMManagedInstanceCore）   4 VPC サブネット：構成図を基に作成する ルートテーブル：作成したサブネットの関連付け、および  Gateway  へのルーティングを設定する InternetGateway、NatGatewayは既に作成されているものを使用する 5 SecurityGroup（ELB） プライベートネットワーク環境（netskopeのグローバルIP）からアクセスできる設定にする   6 SecurityGroup（EC2） ELBのみからアクセスできる設定にする   7 Route53 指定の共通ホストゾーンを利用し、サブドメインのホストゾーンを作成する 共通ホストゾーン：training.aidiv1.com サブドメインのホストゾーン：katou.training.aidiv1.com サブドメインのホストゾーンには以下を設定する Certificate Manager用レコード：CNAME ELB用レコード：Ａ 共通ホストゾーンのゾーン情報にサブドメインのNSレコード情報を登録する 8 ACM 東京リージョンに証明書を発行する（パブリック証明書をDNS検証にて発行）   9 ELB Load balancer typeは「Application」とする セキュリティ強化のため、アクセスログの有効化を実施する 10 EC2 インスタンスタイプは「t3.micro」とする AWS::CloudFormation::Init リソースで以下を実施する AnsibleのInstall S3に配置したAnsible PlaybookファイルをEC2にコピー Ansible Playbookファイルをlocalhost実行する UserDataで以下を実施する 最新のヘルパースクリプトをインストールする cfn-initを実行 AMIは既に作成されている共通AMIを使用する 11 S3 名前は「hrd-d0-s3b-katou」とする 2つの子スタックテンプレート(Network_Stack.yml、Application_quickstart_Stack)とAnsibleのPlaybookファイルを格納しておく     Ansible AWS::CloudFormation::Init リソースでAnsibleをEC2上で実行することにより、スタック作成時にアプリケーションが自動で実行されるようになります。また、AnsibleのPlaybookファイルはS3に配置しておき、AWS::CloudFormation::Init リソースでS3からEC2にPlaybookファイルをダウンロードします。 Playbookファイル # Playbookファイルのrolesを関連付け - hosts: localhost become: true connection: local roles: - linux_common_config - web_ui_config 「linux_common_config」ロールのタスクファイル # yumリポジトリのアップデート - name: Update all packages yum: name: '*' update_only: yes 「web_ui_config」ロールのタスクファイル # Java 17 Amazon Corretoをダウンロード - name: Install Java 17 Amazon Correto yum: name: java-17-amazon-corretto state: installed # JarファイルをS3バケットからローカルホストにダウンロード - name: Copy Jar file from AWS S3 Bucket to localhost command: "aws s3 cp s3://hrd-d0-s3b-katou/web-ui-teamG-katou-0.0.1-SNAPSHOT.jar /tmp/web_app/" # Jarファイルをローカルホストから実行 - name: Run command "java -jar" command: "java -jar /tmp/web_app/web-ui-teamG-katou-0.0.1-SNAPSHOT.jar"   AWS CloudFormation テンプレート 構成図と各リソースの詳細内容を基に作成したテンプレートが以下の3つです。 以下のルートテンプレート（Application_Stack）をCloudFormationでデプロイしてください。 子スタックはネスト構造化してあるので、ルートテンプレートを実行した段階で自動で生成されます。 Application_Stack AWSTemplateFormatVersion: 2010-09-09 Description: Root stack for 2024 Cloud Training Program - TeamG Kato Parameters: #TemplateNetworkのURLを記載 TemplateNetworkUrl: Description: Network template Object URL Type: String Default: "https://hrd-d0-s3b-katou.s3.ap-northeast-1.amazonaws.com/Network_Stack.yml" #TemplateApplicationQuickstartのURLを記載 TemplateApplicationQuickstartUrl: Description: Application Quickstart Template Object URL Type: String Default: "https://hrd-d0-s3b-katou.s3.ap-northeast-1.amazonaws.com/Application_quickstart_Stack.yml" #Tagsに使用するパラメータ SystemId: Description: System ID Type: String Default: "hrd" EnvironmentId: Description: Environment ID Type: String Default: "d0" DeveloperId: Description: Developer ID Type: String Default: "katou-y-test" #サブネット作成に使用するパラメータ VpcId: Type: String Description: VPC ID Default: "vpc-04ac6f2eb1c774c79" PublicSubnet1CidrBlock: Description : CIDR block for Public Subnet1 Type: String Default: "10.0.225.0/24" PublicSubnet2CidrBlock: Description : CIDR block for Public Subnet2 Type: String Default: "10.0.226.0/24" PrivateSubnet1CidrBlock: Description : CIDR block for Private Subnet1 Type: String Default: "10.0.227.0/24" #ルートテーブル作成・ルート追加・ルートテーブルとサブネットの関連付けに使用するパラメータ InternetGatewayId: Type: String Description: Internet Gateway ID Default: "igw-0b1320c68c6590e15" NatGatewayId: Type: String Description: Nat Gateway ID Default: "nat-0be241ae2ac812138" #EC2インスタンス作成に使用するパラメータ InstanceType: Description: EC2 Instance Type Type: String Default: "t3.micro" #ホストゾーン登録・証明書に使用するパラメータ SubDomain: Description: FQDN of the certificate Type: String Default: "katou.training.aidiv1.com" Resources: #Network_Stackが管理するリソースのスタック TemplateNetworkStack: Type: AWS::CloudFormation::Stack Properties: TemplateURL: !Ref TemplateNetworkUrl Parameters: SystemId: !Ref SystemId EnvironmentId: !Ref EnvironmentId DeveloperId: !Ref DeveloperId VpcId: !Ref VpcId CidrBlockForPublicSubnet1: !Ref PublicSubnet1CidrBlock CidrBlockForPublicSubnet2: !Ref PublicSubnet2CidrBlock CidrBlockForPrivateSubnet1: !Ref PrivateSubnet1CidrBlock InternetGatewayId: !Ref InternetGatewayId NatGatewayId: !Ref NatGatewayId #Application_quickstart_Stackが管理するリソースのスタック TemplateApplicationQuickstartStack: DependsOn: TemplateNetworkStack Type: AWS::CloudFormation::Stack Properties: TemplateURL: !Ref TemplateApplicationQuickstartUrl Parameters: SystemId: !Ref SystemId EnvironmentId: !Ref EnvironmentId DeveloperId: !Ref DeveloperId VpcId: !Ref VpcId PublicSubnet1Id: !GetAtt TemplateNetworkStack.Outputs.PublicSubnet1Id PublicSubnet2Id: !GetAtt TemplateNetworkStack.Outputs.PublicSubnet2Id PrivateSubnet1Id: !GetAtt TemplateNetworkStack.Outputs.PrivateSubnet1Id CidrBlockForPrivateSubnet1: !Ref PrivateSubnet1CidrBlock InstanceType: !Ref InstanceType SubDomain: !Ref SubDomain Network_Stack AWSTemplateFormatVersion: 2010-09-09 Description: Network stack for 2024 Cloud Training Program - TeamG Kato Resource - Subnet, Route Parameters: #Tagsに使用するパラメータ SystemId: Description: System ID Type: String EnvironmentId: Description: Environment ID Type: String DeveloperId: Description: Developer ID Type: String #サブネット作成に使用するパラメータ VpcId: Type: String Description: VPC ID CidrBlockForPublicSubnet1: Description : CIDR block for Public Subnet1 Type: String CidrBlockForPublicSubnet2: Description : CIDR block for Public Subnet2 Type: String CidrBlockForPrivateSubnet1: Description : CIDR block for Private Subnet1 Type: String #ルートテーブル作成・ルート追加・ルートテーブルとサブネットの関連付けに使用するパラメータ InternetGatewayId: Type: String Description: Internet Gateway ID NatGatewayId: Type: String Description: Nat Gateway ID Resources: #パブリックサブネット1の作成 PublicSubnet1: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VpcId AvailabilityZone: !Select [ 0, !GetAZs '' ] CidrBlock: !Ref CidrBlockForPublicSubnet1 Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-sub-pub1-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #パブリックサブネット2の作成 PublicSubnet2: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VpcId AvailabilityZone: !Select [ 1, !GetAZs '' ] CidrBlock: !Ref CidrBlockForPublicSubnet2 Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-sub-pub2-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #プライベートサブネット1の作成 PrivateSubnet1: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VpcId AvailabilityZone: !Select [ 0, !GetAZs '' ] CidrBlock: !Ref CidrBlockForPrivateSubnet1 Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-sub-pri1-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #ルートテーブルの作成 RouteTableForPublicSubnet1: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VpcId Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-rtb-pub1-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} RouteTableForPublicSubnet2: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VpcId Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-rtb-pub2-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} RouteTableForPrivateSubnet1: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VpcId Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-rtb-pri1-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #ルートテーブルへのルート追加 InternetGatewayRouteForPublicSubnet1: Type: AWS::EC2::Route Properties: RouteTableId: !Ref RouteTableForPublicSubnet1 DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref InternetGatewayId InternetGatewayRouteForPublicSubnet2: Type: AWS::EC2::Route Properties: RouteTableId: !Ref RouteTableForPublicSubnet2 DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref InternetGatewayId NatGatewayRouteForPrivateSubnet1: Type: AWS::EC2::Route Properties: RouteTableId: !Ref RouteTableForPrivateSubnet1 DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref NatGatewayId #ルートテーブルとサブネットの関連付け PublicSubnet1Association: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PublicSubnet1 RouteTableId: !Ref RouteTableForPublicSubnet1 PublicSubnet2Association: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PublicSubnet2 RouteTableId: !Ref RouteTableForPublicSubnet2 PrivateSubnet1Association: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PrivateSubnet1 RouteTableId: !Ref RouteTableForPrivateSubnet1 Outputs: PublicSubnet1Id: Description: Public Subnet 1 ID Value: !Ref PublicSubnet1 PublicSubnet2Id: Description: Public Subnet 2 ID Value: !Ref PublicSubnet2 PrivateSubnet1Id: Description: Private Subnet 1 ID Value: !Ref PrivateSubnet1 Application_quickstart_Stack AWSTemplateFormatVersion: 2010-09-09 Description: Application Quickstart Stack for 2024 Cloud Training Program - TeamG Kato Resource - IAM, SecurityGroup, Route53, ACM, ELB, EC2 Parameters: #Tagsに使用するパラメータ SystemId: Description: System ID Type: String EnvironmentId: Description: Environment ID Type: String DeveloperId: Description: Developer ID Type: String #各種ネットワーク設定パラメータ VpcId: Description: VPC ID Type: String PublicSubnet1Id: Description: Public Subnet 1 ID Type: String PublicSubnet2Id: Description: Public Subnet 2 ID Type: String PrivateSubnet1Id: Description: Private Subnet 1 ID Type: String CidrBlockForPrivateSubnet1: Description : CIDR block for Private Subnet1 Type: String #EC2インスタンス作成に使用するパラメータ InstanceType: Description: EC2 Instance Type Type: String #ホストゾーン登録・証明書に使用するパラメータ SubDomain: Description: FQDN of the certificate Type: String Resources: #IAMロールを作成 IAMRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ${SystemId}-${EnvironmentId}-iam-ec2-${DeveloperId} #どのリソースに対してどんなアクションをするかを記載 AssumeRolePolicyDocument: Statement: - Effect: Allow Principal: Service: - ec2.amazonaws.com Action: - 'sts:AssumeRole' #アクセス権限ポリシーを記載 ManagedPolicyArns: - "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess" - "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore" Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-iam-ec2-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #インスタンスプロファイルの作成 InstanceProfile: Type: 'AWS::IAM::InstanceProfile' Properties: Path: '/' Roles: - !Ref IAMRole # IAMロールへの参照 #セキュリティグループ（ELB）の作成 SecurityGroupForELB: Type: AWS::EC2::SecurityGroup Properties: GroupName: !Sub ${SystemId}-${EnvironmentId}-sec-elb-${DeveloperId} GroupDescription: Security Group for ELB VpcId: !Ref VpcId Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-sec-elb-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #インバウンドルール・アウトバンドルールを追加 #netskopeのグローバルIPアドレスからELBへのHTTPS通信 SecurityGroupIngress1HTTPSForELB: Type: AWS::EC2::SecurityGroupIngress Properties: GroupId: !Ref SecurityGroupForELB IpProtocol: tcp FromPort: 443 ToPort: 443 CidrIp: xxx.xxx.xxx.0/xx #netskopeのグローバルIPアドレスからELBへのHTTPS通信 SecurityGroupIngress2HTTPSForELB: Type: AWS::EC2::SecurityGroupIngress Properties: GroupId: !Ref SecurityGroupForELB IpProtocol: tcp FromPort: 443 ToPort: 443 CidrIp: xxx.xxx.xxx.0/xx #netskopeのグローバルIPアドレスからELBへのHTTPS通信 SecurityGroupIngress3HTTPSForELB: Type: AWS::EC2::SecurityGroupIngress Properties: GroupId: !Ref SecurityGroupForELB IpProtocol: tcp FromPort: 443 ToPort: 443 CidrIp: xxx.xxx.xxx.0/xx #プライベートサブネットからELBへの8080通信 SecurityGroupIngressCustomTCP8080ForELB: Type: AWS::EC2::SecurityGroupIngress Properties: GroupId: !Ref SecurityGroupForELB IpProtocol: tcp FromPort: 8080 ToPort: 8080 CidrIp: !Ref CidrBlockForPrivateSubnet1 #セキュリティグループ（EC2）の作成 SecurityGroupForEC2: Type: AWS::EC2::SecurityGroup Properties: GroupName: !Sub ${SystemId}-${EnvironmentId}-sec-ec2-${DeveloperId} GroupDescription: Security Group for EC2 VpcId: !Ref VpcId Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-sec-ec2-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #ELBからEC2への8080通信 SecurityGroupIngressCustomTCP8080ForEC2: Type: AWS::EC2::SecurityGroupIngress Properties: GroupId: !Ref SecurityGroupForEC2 IpProtocol: tcp FromPort: 8080 ToPort: 8080 SourceSecurityGroupId: !Ref SecurityGroupForELB #EC2インスタンスの作成 EC2: Type: AWS::EC2::Instance #Metadataの記述 Metadata: AWS::CloudFormation::Init: configSets: Default: - InstallAnsible - CreateDirectory - Download - RunAnsible #Ansibleをインストールするためのデータ InstallAnsible: packages: yum: ansible: [] #各種ディレクトリを作成するための実行コマンドデータ CreateDirectory: commands: mkdirWebApp: command: "mkdir -p /tmp/web_app" mkdirAnsible: command: "mkdir -p /tmp/ansible" mkdirLinuxCommonConfig: command: "mkdir -p /tmp/ansible/roles/linux_common_config/tasks" mkdirWebUiConfig: command: "mkdir -p /tmp/ansible/roles/web_ui_config/tasks" #AnsibleのPlaybookをS3バケットからダウンロードするためのデータ Download: commands: downloadWebUiStartup: command: aws s3 cp s3://hrd-d0-s3b-katou/ansible/web_ui_startup.yml /tmp/ansible/ downloadLinuxCommonConfig: command: aws s3 cp s3://hrd-d0-s3b-katou/ansible/roles/linux_common_config/tasks/main.yml /tmp/ansible/roles/linux_common_config/tasks/ downloadWebUiConfig: command: aws s3 cp s3://hrd-d0-s3b-katou/ansible/roles/web_ui_config/tasks/main.yml /tmp/ansible/roles/web_ui_config/tasks/ #AnsibleにおけるPlaybookの実行コマンドデータ RunAnsible: commands: runWebUiStartup: command: "ansible-playbook -c local /tmp/ansible/web_ui_startup.yml" Properties: ImageId: ami-0cb4639ca5eb232fc InstanceType: !Ref InstanceType SubnetId: !Ref PrivateSubnet1Id SecurityGroupIds: - !Ref SecurityGroupForEC2 IamInstanceProfile: !Ref InstanceProfile Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-ec2-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #UserDataの記述 UserData: Fn::Base64: !Sub | #!/bin/bash yum install -y aws-cfn-bootstrap /opt/aws/bin/cfn-init -v --stack ${AWS::StackName} --resource EC2 --configsets Default --region ${AWS::Region} #ELBの作成 ApplicationLoadBalancer: Type: AWS::ElasticLoadBalancingV2::LoadBalancer Properties: Name: !Sub ${SystemId}-${EnvironmentId}-elb-${DeveloperId} Subnets: - !Ref PublicSubnet1Id - !Ref PublicSubnet2Id SecurityGroups: - !Ref SecurityGroupForELB Scheme: internet-facing Type: application LoadBalancerAttributes: - Key: access_logs.s3.enabled Value: true - Key: access_logs.s3.bucket Value: lms-d0-s3-logcollection Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-elb-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #ELBのリスナー設定 ListenerForELB: Type: AWS::ElasticLoadBalancingV2::Listener Properties: LoadBalancerArn: !Ref ApplicationLoadBalancer Port: 443 Protocol: HTTPS Certificates: - CertificateArn: !Ref Certificate DefaultActions: - Type: forward TargetGroupArn: !Ref TargetGroup #ターゲットグループ作成 TargetGroup: Type: AWS::ElasticLoadBalancingV2::TargetGroup Properties: VpcId: !Ref VpcId Name: !Sub ${SystemId}-${EnvironmentId}-trg-${DeveloperId} Protocol: HTTP Port: 8080 HealthCheckProtocol: HTTP HealthCheckPort: 8080 HealthCheckPath: "/actuator/health" HealthCheckTimeoutSeconds: 10 HealthCheckIntervalSeconds: 20 HealthyThresholdCount: 3 UnhealthyThresholdCount: 2 Targets: - Id: !Ref EC2 Port: 8080 TargetType: instance Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-trg-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #Route53のホストゾーン作成 HostedZone: Type: AWS::Route53::HostedZone Properties: HostedZoneConfig: Comment: "Subdomain of training.aidiv1.com" Name: !Ref SubDomain HostedZoneTags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-r53-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} #ホストゾーンへのレコード登録 #ELBのAレコード登録 ARecordSetForELB: Type: AWS::Route53::RecordSet Properties: HostedZoneId: !Ref HostedZone Name: !Ref SubDomain Type: A AliasTarget: HostedZoneId: !GetAtt ApplicationLoadBalancer.CanonicalHostedZoneID DNSName: !GetAtt ApplicationLoadBalancer.DNSName #training.aidiv1.comへのNSレコード登録 NSRecordSetForParentDomain: Type: AWS::Route53::RecordSet Properties: HostedZoneId: Z037543234RUL8GGC5CBK Name: !Ref SubDomain Type: NS TTL: 300 ResourceRecords: !GetAtt HostedZone.NameServers #Certificate Manager Certificate: Type: AWS::CertificateManager::Certificate Properties: DomainName: !Ref SubDomain ValidationMethod: DNS DomainValidationOptions: - DomainName: !Ref SubDomain HostedZoneId: !Ref HostedZone Tags: - Key: Name Value: !Sub ${SystemId}-${EnvironmentId}-acm-${DeveloperId} - Key: Cost Value: !Sub ${SystemId}-${EnvironmentId}-${DeveloperId} - Key: Env Value: !Sub ${SystemId}-${EnvironmentId} 実行画面 CloudFormation上でルートテンプレート「Application_Stack」を実行します。 AWSマネジメントコンソール上でCloudFormationを検索し、「スタックの作成」を押下します。 ルートテンプレート「Application_Stack」をアップロードします。 適当なスタック名を入力し、下までスクロールし「次へ」を押下します。　　　　　　 下までスクロールし、二つのチェックボックスにチェックを入れ、「次へ」を押下します。 下までスクロールし、「送信」を押下するとルートテンプレートが実行されます。 実行されると親スタックが作成され、子スタックが二つ作成されます。リソースが全て作成されると以下の画面のようになります。 プライベートネットワーク環境のPCから「https://katou.training.aidiv1.com」にアクセスします。以下のような画面が表示されたらWebアプリケーションの自動実行が成功となります。   注意点 AnsibleとCloudFormationを使用した際に、個人的につまづいた点を共有します。 AnsibleをS3からEC2へダウンロードする際に、Ansibleのディレクトリ構造を保持したままPlaybookファイルをダウンロードしてください。ディレクトリ構造が保たれていないと、適切なロールのタスクが実行されません。 AnsibleのPlaybookファイルに「become: true」を記述していないと、権限がなくコマンドが実行されない場合があります。「become: true」は一時的にroot権限を与えるものです。 Spring Bootアプリケーションのリッスンポート番号は8080なので、私のように「HTTPプロトコルを使用するのでポート番号は80」と決めつけてしまうと痛い目をみます。 共通ホストゾーンのゾーン情報にサブドメインのNSレコード情報を登録しないと、共通ホストゾーンからのサブドメインの名前解決がうまくいきません。 Certificate Managerでサブドメインの証明書をリクエストする際に検証方法としてDNS検証を選んだ場合、CloudFormationではデフォルトで、サブドメインのホストゾーンにCNAMEゾーン情報が登録されます。   最後に 以前行ったハンズオンではAWSをマネジメントコンソール上から画面をポチポチしてインフラ構築をしていたので、一度リソースを削除してから同じインフラを構築しようとなるととても面倒でした。それがCloudFormationとAnsibleを利用することで何度でも同じインフラを構築することができ、なおかつ自動で行ってくれるので、一度コードを書いてしまえばとても楽にインフラを構築できることに感動いたしました。 次回の記事では案件で得たナレッジなどを共有できればと思います。