こんにちは。SCSK株式会社の安藤です。 2024年6月4日にリリースされた最新バージョンであるZabbix 7.0 LTSへ、5.0 LTSから簡単にバージョンアップしてみたいと思います。 ※新規インストールの場合は、以下の記事を参照ください。 Zabbix 7.0 LTSをインストールしてみた 最新バージョンであるZabbix 7.0 LTSがリリースされましたので、AWS上にインストールしてみたいと思います。 また、インストールするために必要な手順を本記事にて記載いたします。 blog.usize-tech.com 2024.06.12 Zabbixとは まずはZabbixの説明を簡単にさせていただきます。 Zabbixは、エンタープライズ対応のオープンソース統合監視ツールです。 サービスやそれを支える ITシステム(サーバ、ネットワーク機器等)の状態を把握し、障害の予兆やサービスへ影響を及ぼす事象が発生した際に、システム管理者やオペレータに通知を行うオープンソースの統合監視ソリューションです。 数万デバイス規模のエンタープライズ環境でも多数の稼動実績を誇っています。 Zabbixの詳細情報については、以下をご確認ください。 Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution ZabbixはITインフラストラクチャ・コンポーネントの可用性やパフォーマンスを監視するためのエンタープライス向けソフトウェアです。Zabbixはオープンソース・ソフトウェアとして開発されており、無料でダウンロードいただくことが可能です。 www.zabbix.com   バージョンアップ手順 早速、Zabbix5.0から7.0へバージョンアップしていきたいと思います。 今回の構成 今回の構成は以下のとおりです。 ZABBIX VERSION: 5.0.42 OS DISTRIBUTION: Red Hat Enterprise Linux OS VERSION: 8.2 DATABASE: MySQL 8.0.36 WEB/AP SERVER: Apache 2.4.37 / PHP-fpm 7.2.24 SELinux: 無効 Firewalld: 無効   関連ミドルウェアのバージョンアップ 各ミドルウェアの対応バージョンは以下の通りです。事前に、Zabbix 7.0の動作が可能なバージョンまで、バージョンアップしておく必要があります。   5.0 LTS 7.0 LTS Apache 1.3.12 or later 2.4 or later PHP 7.2.0 or later 8.0.0 – 8.3.X MySQL 5.7.X – 8.4.X 8.0.30 – 8.4.X Zabbix 7.0リポジトリの設定とZabbixのバージョンアップ Zabbix 7.0 のリポジトリを設定します。 # Zabbix 7.0 リポジトリの設定 rpm -Fvh https://repo.zabbix.com/zabbix/7.0/rhel/8/x86_64//zabbix-release-7.0-1.el8.noarch.rpm dnf clean all 次に、Zabbix関連のパッケージをバージョンアップします。 # Zabbix関連パッケージのバージョンアップ dnf update zabbix-agent zabbix-apache-conf zabbix-server-mysql zabbix-web zabbix-web-japanese zabbix-web-mysql インストールされているZabbixパッケージのバージョンを確認します。 # インストールされているZabbixパッケージのバージョンの確認 dnf list --installed |grep zabbix これだけで完了です。とっても簡単です！ Zabbix Serverのサービス再起動とデータベースのアップグレード Zabbix Serverのバージョンアップ後、Zabbix Serverのサービスを再起動すると、自動的にZabbixのデータベースのアップグレードが開始されます。データベースのアップグレード時には、ログに以下のような出力があります。 2623:YYYYMMDD:194015.890 using configuration file: /etc/zabbix/zabbix_server.conf 2623:YYYYMMDD:194015.941 current database version (mandatory/optional): 05000000/05000007 2623:YYYYMMDD:194015.942 required mandatory version: 07000000 2623:YYYYMMDD:194015.942 mandatory patches were found 2623:YYYYMMDD:194015.943 starting automatic database upgrade 2623:YYYYMMDD:194016.159 completed 0% of database upgrade 2623:YYYYMMDD:194017.273 completed 1% of database upgrade 2623:YYYYMMDD:194019.414 completed 2% of database upgrade 2623:YYYYMMDD:194021.865 completed 3% of database upgrade ・・・ 5.0 LTSのデータベースバージョン「05000000」であるのに対し、7.0 LTSの「07000000」が必要であると、出力があります。 その後、自動的にデータベースのアップグレードが開始されていることがわかります。   バージョンアップ中の挙動 バージョンアップ中に、以下のような挙動をすることがあります。 データベースのアップグレード中にWeb管理画面を表示 データベースのアップグレード中にWeb管理画面にアクセスすると、Zabbixデータベースのバージョンが要件を満たしていない旨のエラーメッセージが表示されます。 データベースのアップグレードを中断 データベースのアップグレードが中断した場合は、Zabbix Serverのサービスを再起動することで、中断した箇所からアップグレード処理が再開されます。   まとめ Zabbix5.0から7.0へのバージョンアップは、5.0→6.0→7.0と段階を踏むことなく、5.0から7.0へ、一度で簡単にバージョンアップすることができました。 最後まで読んでいただき、ありがとうございました。   最後に 弊社では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 稲葉・川原・間世田です。 6月20日と21日に幕張メッセで開催された「 AWS Summit Japan 2024 」に参加してきました！本イベントは、日本最大のAWSに関する学びの場であり、2日間にわたってさまざまなセッションや展示が行われました。 私たち3名で各セッションやブースを回りましたので、その感想やレポートを共有したいと思います。 イベント概要 AWS Summit Japan 2024は、日本最大の“AWS を学ぶイベント”として、多彩なプログラムが用意されていました。 主に以下のような内容で構成されております。 基調講演 150を超えるセッション 250を超えるEXPOコンテンツ DeepRacerリーグや開発者向けワークショップ、さまざまな AWS の質問をすることができる「Ask an Expert/Ask an Speaker」   基調講演やセッションなどには、AWSを導入しているパートナー企業やユーザー企業なども参画しています。自社で導入してきたAWSの知見などを発表し、他のAWS利用者がそれを見て学ぶことができるイベントになっております。 基調講演 1日目：AWSと創る次の時代 1日目の基調講演では「AWSと創る次の時代」という題で、既に活用されているAIの活用事例について発表され、後半にはAWSの新サービスの発表も行われました。 AIの活用事例では、画像認識を使用して養殖している魚の病原体を検知したり、データの傾向から病気の予兆を検知するなどさまざまな活用事例が紹介されており、非常に興味深かったです。 また善のためのAIが強調されていて、持続可能な社会の実現に向けた人類の課題に対して、AIでどのように課題を解決するかといった内容が多かった印象です。 後半のAWSの新サービス発表では、AI系のサービスが多く発表されました。 特にClaude3の東京リージョン対応やAmazon Q Businessの日本語版対応が、会場を大きく盛りあげていました。 2日目：ビルダーとテクノロジーが加速する次のイノベーション 生成AI および AI/ML マーケット戦略担当のラフール パサック氏が登壇され、生成AIによる新しい時代を、それらの実現に向けての AWS の戦略や支援を、これまで日本のお客様と創出してきたイノベーション事例とともに紹介されました。 セッションでは、複数の業界におけるクラウドテクノロジーの革新が焦点となりました。金融業界では、SBIがインフラストラクチャをコード化し、効率化を図っています。自動車業界では、TIER 4が大量のテスト資料から開発シミュレーションを作成し、エッジコンピューティングへの展開を推進しています。通信業界では、docomoが5Gの商用展開でAWSを選定し、消費電力を大幅に削減する取り組みを行っています。 また、プロジェクトKuiperによる衛星群の運用や、ANAがAWSにデータ分析基盤を移行し、グループ全体のデータを集約・分析することで競争力を高めています。これらの事例は、データの活用が企業の競争力を飛躍的に向上させ、AIがビジネスの差別化に重要な役割を果たしていると感じました。 さらに、AWSのLLM開発支援プログラムや新しい推論コンポーネントの導入が、デジタル革命が多岐にわたる産業で進行していることが強調されました。これにより、企業は柔軟に業務を変革し、進化を続けることが可能になっています。 電通とJR東海の事例も取り上げられ、電通はAIを活用したマーケティング戦略の展開や、顧客のデータドリブンな分析を通じたサービスの最適化を進めています。一方、JR東海はリニア中央新幹線の運行管理において、地上設備からのリアルタイムデータを活用し、運行計画の最適化と運行監視の効率化を図っています。これらの取り組みは、AWSのテクノロジーを駆使してデータ中心の革新を実現し、それぞれの業界において革新的な成果をもたらしています。 セッションの締めくくりでは、ラフール氏から「あなたが作り上げるのはどんな魔法ですか？」と問いかけられました。これからもAWSを活用した革新がさらに進展し、ビジネスにおける魔法のような変革をもたらすことが期待される素晴らしいセッションでした。   セッション 1日目 Amazon Bedrockの活用によるデジタル教育サービスの生成AI機能拡張 パートナーセッション 【スピーカー】中村 寿志 氏　株式会社 学研メソッド 取締役 学研様の生成AI活用事例についてお話しされていました。 学研様では生徒が学習するためのWebシステムを運用しており、学習情報の取得や独自にチューニングした分析システムで学習情報を分析していました。 このWebシステムに対し、生成AIを活用するアイデアがお話しされていました。 学習情報を分析した結果を生成AIが生徒一人に合わせてフィードバックしたり、生徒の質問に生成AIアシスタントが対応し生徒一人ひとりに合わせたヒントを出したり、生徒に合わせた類題を提示したりとたくさんのアイデアがお話しされていました。 このセッションで機械と人間のインタフェースとして生成AIは特に有用だなと感じました。 自社データを用いた生成AIの活用事例 AWSセッション 【スピーカー】中島 佑樹氏　アマゾン ウェブ サービス ジャパン合同会社　技術統括本部 エンタープライズ技術本部 本セッションでは、生成AIの導入におけるデータの重要性と活用戦略について事例を用いて詳細に解説していました。 まず、生成AIを効果的に活用するためには、良質なデータが不可欠であり、データ適用方式として、検索拡張⽣成 (RAG)、Fine-turning、継続的事前学習の3つの方法が紹介され、それぞれのメリットや具体的な事例が示されました。 具体的な事例としては、RIZAPテクノロジーズ様が社内問い合わせ検索システムを生成AIで構築したケースが紹介されました。このシステム導入により、従業員の問い合わせ対応工数が大幅に削減され、業務効率が向上しました。また、カラクリ株式会社様がカスタマーサポート向けに誠実かつ自然な返答を提供する生成AIを3日で学習させた事例も取り上げられ、生成AIの実用性が強調されていました。 また、データ戦略の重要性について、生成AIを活用するための3つの観点が示されました。 独⾃のカスタムデータを使⽤して AI アプリケーションをする 独自データを活用して他社との差別化を図る。 既存のデータ基盤上で⽣成 AI を活⽤する 既存のデータ基盤を活用して生成AIワークロードに適用。 生成AIアプリケーションを監査する 生成AIアプリケーションの監査機能をONにして責任あるAIを実践。 特に、責任あるAIの実践には生成AIアプリケーションの監査機能をONにすることが第一歩として重要であると強調されました。AWSのリソースを活用し、透明性や公平性を確保するための具体的な方法も提供されています。 このセッションを通じて、生成AIの導入にはデータの質と戦略が非常に重要であることを再認識しました。特に、実際の事例を通じて、生成AIがどのように業務効率を向上させるかが具体的に理解できました。今後のビジネスにおいて、生成AIの活用がどのように進化し、どのように実用化されるのか非常に楽しみです。AWSの提供する多様なツールとサポートを活用することで、企業はより効率的に生成AIを導入し、競争力を高めることができるのだと思いました。 生成AIが変える、データアナリティクス AWSセッション 【スピーカー】西澤 祐介氏　アマゾン ウェブ サービス ジャパン合同会社 プロフェッショナルサービス本部 ビッグデータコンサルト 生成AIがデータアナリティクスと連携することで何ができるようになったのかお話しされていました。 生成AIとAmazonDataZoneの連携では、データの説明やデータの分析例などを出力でき、AWS Glueとの連携では、自然言語でETLジョブを作成できるとお話しされていました。 また、生成AIとAmazon Redshift クエリエディタが連携することで、自然言語からSQLを生成してデータ分析可能だとお話しされていました。 Quicksightは生成AIと連携することで多くの恩恵を受けられるとお話しされていました。 自然言語でダッシュボードや計算フィールドを作成できたり、ダッシュボードに対してQ&Aインタフェースを提供し質問できるようになると紹介されていました。他にはデータからストーリーテリングを生成できるようになると紹介されていました。 このセッションでは特にQuicksightと生成AIの連携のお話しが興味深く、今後グラフを使用して発表するときはQuicksightと生成AIをぜひとも使用したいと思いました。 AWS 環境におけるセキュリティ調査の高度化と生成 AI 活用 AWSセッション 【スピーカー】 勝原 達也氏　アマゾン ウェブ サービス ジャパン合同会社 セキュリティソリューションアーキテクト AWS環境でのセキュリティインシデント対応をどのように高度化するかについてのセッションでした。 セッションのポイントを以下にまとめました。 AWSの特性がセキュリティ分析を支える 高い可視性 ：AWSのサービスは詳細なログを提供し、システムの状態を把握しやすくしています。 柔軟な自動化機能 ：自動化により、迅速かつ効率的なインシデント対応が可能です。 Amazon GuardDuty ：脅威検知に特化したサービスで、インシデントの初期検知を担います。 Amazon Detective ：詳細なログ分析を行うサービスで、脅威の根本原因を特定します。 セッションでは、仮想的なセキュリティインシデントを通じて、どのように脅威が検知されるかを具体的に説明されていて、GuardDutyが検知する脅威の種類や、Amazon Detectiveを用いた詳細なログ分析の方法が紹介されました。具体的な脅威検知の流れとしては、次のようなプロセスが示されていました。 GuardDutyの検知 ：偵察活動、インスタンス侵害、アカウント侵害などの脅威を検知。 Detectiveでの詳細なログ分析 ：検知された脅威を基に、詳細なログ分析を実施。 生成AIの活用 ：自然言語でのクエリ生成により、分析作業が効率化。 生成AIはセキュリティ専門家を即座に置き換えるものではないですが、その活用により専⾨家は優れた成果を得ることができると述べられました。AWSのナレッジと自社固有の構成情報を基に、生成AIが優れたインサイトを提供し、セキュリティチームを強力にサポートしてくれます。 AWSのセキュリティサービスと生成AIの組み合わせにより、セキュリティ分析がより効率的かつ効果的に行える未来が見えてきたと思います。今後もAWSのセキュリティサービスの進化に注目していきたいです。 2日目 なぜ、AWS 活用のメリットを実感できないのか？ ～内製化・運用改善の考え方～ パートナーセッション 【スピーカー】浅野 佑貴氏　株式会社ＢｅｅＸ　事業開発室 AWS Partnerから見た内製化支援の活用方法のナレッジを共有するセッションでした。 まず、内製化支援の活用方法を考える前に、AWSのメリットを実感できない理由として以下が挙げられていました。 継続的な変更・改善を行うためのコスト・プロセスを確保していない 「どの様な課題を解決することに使えるアップデートか？」を考えていない 前提として、AWSを活用して実現したいことは「ビジネス環境の変化に追随し、最新IT技術を取り込む」ことです。 しかし現状は、AWSサービスのアップデートが想像以上に速く・多く、自分たちに必要なアップデートが何か見極められなかったり、継続的な構成変更を計画せず、移行初期からのメリット享受を優先してしまったりすることが多いようです。 そこから考えると、内製化を進めるためのポイントは以下となります。 改善のための専任リソース(Teams)を確保する 通常業務を行ったまま改善業務を行うことは負担が大きいです。そのため専任Teamが必要とのことですが、会社の”理解”を得ることが個人的には一番難関だと感じました。セッションでも、Teamが機能するために必要なカルチャー/会社の仕組みの整備には時間がかかるため、3つめのポイントの実践が推奨されていました。 不足する役割・スキルをサポートするパートナーとの協業 必ずしもAWSサービス固有の深い知識が必要な訳では無いです。より重要なのは、担当システムの課題がどの様な技術課題なのかを把握し、どの様な課題を解決することに使えるかを考えることです。CCoEによるナレッジ収集・共有は組織的なソリューションの一つですが、ここは専門家(AWSパートナー)のナレッジを活用することで補うことができます。 取り組みレベルは段階的に成熟させる 内製化とは自社リソースですべて実施するものではなく、どこまでを自社で行うかを見極めることが必要です。例として3段階のアプローチが挙げられており、自社で行う範囲として、Lv1：企画の一部⇒Lv2：企画+開発の一部⇒Lv3：企画から運用まで また、どのレベルが正解といったわけではなく、内製化を行うシステム・領域によってレベルを使い分けることが重要とのことでした。 弊社も内製化支援を行っており、私も支援を行った経験があったため、非常に参考となるセッションでした。 AWS技術支援 テクニカルエスコートサービス｜SCSK株式会社 テクニカルエスコートサービスはAWSの導入に関して課題に直面されているお客様にAWS認定資格保有者が参画いたします。 www.scsk.jp NTT の生成AI「tsuzumi」とともに挑む新たなチャレンジ（AWS LLM 開発支援プログラムを 用いた技術検証等） パートナーセッション 【スピーカー】爪長 美菜子氏　日本電信電話株式会社 研究開発マーケティング本部 執行役員　マーケティング部門長 NTT版LLM「tsuzumi」の紹介と活用領域、案件対応から浮き出たLLM利活用時の主な課題が伝えられたセッションでした。 「tsuzumi」の特徴として、軽量・高い言語性能・高カスタマイズ性・マルチモーダル性を挙げていました。特にパラメタサイズは、GPT-3の1/25である7Bサイズと非常に軽量のようです。驚くべきことに、「図表・イラストの読解（infoVQA）」と「複数画像の複合読解（SlideVQA）」ではGPT-3.5、GPT-4を凌ぐ精度となっていました。 LLM利活用時の主な課題として「精度」・「精度のゴール設定」・「データ整備」の三本を挙げていました。 精度 精度40%〜70％から出発すること チャンキング、検索手法の精査、pre-retrieval等で精度向上が必要であること 精度のゴール設定 PJ開始時に精度の定義合わせが重要であること データ整備 フォーマットの違い等でのデータ整備にコストがかかる PoCを行っている方も多いですが、データ整備に課題を感じている方も多いのではないでしょうか。 私もデータ整備を行ってくれる生成AIないかなぁ〜と日々感じています… 余談ですが、セッション冒頭で名前の由来も話されており、「雅楽で用いられる鼓が演奏の流れを統率する役割を担っていることになぞらえ、これからの自然言語処理技術の発展をリードしていく存在をめざす」とのことでした。日本らしく、素敵な名前です。 AIアプリ開発プロジェクトの始め方 AWSセッション 【スピーカー】⼤渕 ⿇莉氏　アマゾン ウェブ サービス ジャパン合同会社　サービス&テクノロジー事業統括本部 セッションの冒頭では、AIの基本的な概念とそれらの違いについてお話されていて、特に生成AIについては、テラバイト規模のデータで学習し、追加学習なしに人間と同等のコンテンツ生成能力を持つことが強調されました。AIの最大の特徴として「AIは間違えることがある（精度100%にはならない）」という点が挙げられ、入力が決まれば出力の「予測値」が決まるため、単純なロジックでは計算できない現象を予測する際に使われることが多く、必ず誤差が生じることが説明されました。 また、生成AIは、プロンプトエンジニアリングを通じて多様な表現形式や応答の微調整が可能です。しかし、プロンプトが肥大化する場合にはファインチューニングの検討が必要となります。 AIを自社アプリに組み込む具体的なステップは以下になります。 課題のフレーミング データ処理 モデル開発 モデルのデプロイ モデル性能監視 ビジネスゴールがないと、評価指標や評価データを作れず、AIが正しく機能しているかを評価できないため、ビジネスゴールの設定が非常に重要になります。 安全で信頼性の高い生成AIソリューションの実現には、生成AIを利用する際の入出力データの適切性を確保するためのガードレールやモデレーション機能が重要です。Amazon Bedrock や Amazon Rekognition などのAWSサービスを活用することで、より安全で信頼性の高い生成AIソリューションを構築することが可能となります。 このセッションを通じて、AIアプリ開発プロジェクトの始め方と、従来のAIと生成AIの違い、AWSが提供する豊富なAIサービスについて深く理解することができました。特に、ビジネスゴールの設定の重要性や、適切なAIサービスの選択が成功の鍵であると感じました。AWSのAIサービスを活用することで、AIアプリ開発がより身近で現実的なものになると感じました。 チームのつながりをInfrastructure as Codeでデザインする AWSセッション 【スピーカー】高野 賢司氏　アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジック製造グループ チームがDevOpsできるようになるにはどのような障壁を乗り越えないといけないのかというお話でした。 従来の分断されたチームでは、それぞれのチームがタスクの完了だけに注目し、フィードバック受け取って改善しなくなるという問題点がありました。 目標とするDevOpsできるチームは、コードをコミュニケーションの中心に置くことでフィードバックに基づいた継続的な改善を行うことができるチームとお話しされていました。 目標達成するためにはインフラストラクチャをコードで管理すること、バージョン管理ツールでコードを管理すること、チーム全員がコードを理解できることなどが挙げられていました。 DevOpsをできるようになるまでの手順を段階的に紹介されていたので非常に勉強になりました。 Amazon CodeCatalyst と Amazon Q で開発者の生産性を向上！ – AI アシスタントの活用方法 – AWSセッション 【スピーカー】柳久保 友貴氏　アマゾン ウェブ サービス ジャパン合同会社 デジタルサービス技術本部 ISV/SaaSソリューション部 昨年11月のアップデートにて、Amazon CodeCatlyst での Amazon Q によるソフトウェア開発タスク支援が発表されており、本セッションではそのデモンストレーションが行われました。 Amazon CodeCatalyst、Amazon Q の機能開発 (プレビュー版) を発表 aws.amazon.com 具体的にはAmazon Q によって、単体テストの作成やPull Requestのコメント作成・レビューコメントの要約等です。驚くべきこと「Title」欄に一文記入するだけで、前述の処理の作成を行ってくれていました。エンジニア初心者でも簡単にアプリケーション作成を行えるでしょう。（生成AIのコードの正確性の理解は必要ですが。） また、「レビューコメント」の作成によって、大規模変更の際に大きくエンジニアの負担を減らすことができます。今までは大きな変更の際、差分が多くなってしまい、そのすべてを確認し、理解する必要がありました。この機能により、エンジニアの負担を大幅に削減することができます。 データセンターのラックぜんぶ抜く！SCSKだからできる脱オンプレの秘策とは？ パートナーセッション 【スピーカー】岸岡 学氏　ＳＣＳＫ株式会社　クラウドサービス事業本部 事業推進部 クラウド営業課長 髙島 豊徳氏　沖電気工業株式会社 常務理事 情報責任者 本セッションでは、沖電気工業株式会社（OKI）のCIOである高島様と共に、実際のクラウド移行プロジェクトの具体的な取り組みと成功の秘訣について語られました。クラウドのメリットを理解し活用を進めようとする企業は多いものの、さまざまな理由で踏みとどまっている企業が多く存在するのが現実です。2日目の最後のセッションにもかかわらず、多くの方々が来場していて、クラウド移行に関する関心の高さを感じました。 沖電気工業株式会社様は広範な事業領域と高いセキュリティ要件を持つため、膨大な業務システムのクラウド移行には多くの課題がありました。特に、事業ごとに異なるシステム要件や古いシステムのモダナイズ、クラウド移行が難しいシステムが存在していました。さらに、2026年までに約800台のサーバ（100ラック相当）を含む現行データセンターの移転・移行が必要で、クラウド利用促進とシステム刷新を同時に進める必要がありました。 この課題に対し、ハード面、ソフト面、マネジメント面の三位一体のアプローチが成功の鍵となりました。 ハード面（設備/体制） 最新データセンター、自社プライベートクラウドとAWSへの直接コネクティビティを提供し、営業・技術一体となったデリバリ体制を整備したこと ソフト面（技術/サービス） オンプレミスも把握しているAWSスペシャリストによる全体計画、プロジェクト推進、最新技術への追随とAWS社と共同で立ち上げた移行アセスメント、移行仕分け、移行作業パッケージを利用した迅速で安心安全な移行 マネジメント面 当初の目的を定期的に経営レベルで見直し、共通ゴールをぶらさずに、現場メンバーがプロジェクトに専念できることを最優先したこと 今後は、クラウドシフト/サーバレス化、そしてアプリケーションのモダナイゼーションを目指しています。 今回のセッションを通じて、SCSKとOKI様がどのようにしてデータセンターの完全移行を実現したか、その具体的な施策と成功の秘訣を深く理解することができました。特に、SCSKのAWSに対する深い理解と高い技術力が、脱オンプレミスを実現する上で不可欠な要素であると強く感じました。 SCSKは、AWS戦略協業パートナーとして、トータルサポートを提供していて、豊富なサービスメニューと延べ2000を超えるAWS認定技術者が、お客様のクラウドジャーニーを最適なルートで案内しています。Lift & Shiftフェーズでの課題に対して、これまで培ったノウハウを活かし、ビジネスに必要なITサービスをフルラインナップで提供することができます。 クラウド移行を考えている企業にとって、今回のセッションは非常に参考になる内容でした。SCSKの技術力とサポート体制により、多くの企業が安心してクラウドへの移行を進めることができると確信しました。   EXPO AWS DeepRacer 白熱の戦いが繰り広げられていました。私が観戦したときは8秒台が決勝ラインでしたが、最終結果はどうなったのでしょう…？   AWS Village 生成AI・Developer・Industry・セキュリティのテーマごとに4つのエリアに分かれて、様々なソリューションの個々の基本的な機能から選定や組み合わせまで、実際に動くデモを見ながら学ぶことができました。 個人的に一番テンションがあがったのが、「 AWS Snowball Edge 」の展示でした。 他の方のレポートを見ると、触ったり持つこともできたようです。（持ち上げたかった！！！） 認定者ラウンジ AWS 認定ごとにシールがもらえました。品切れのため1枚しか貰えなかったので、来年は早めにラウンジへ行こうと思います。 その他の思い出 基調講演前に、田中知之（FPM）氏がウエルカムDJパフォーマンスを披露されており、厳かでありながら魅惑的かつ高揚感高まるステージでした。 （氏のRemix作品である、三日月サンセット -FPM EVERLUST Mix- を聞きながらこのレポートを書いていますが、最高です。） 先着でお弁当とクッションがもらえました。AWS Summitを通じて、クッションにはお世話になりました。 感想 疲れを忘れるぐらい、刺激的で素晴らしい体験でした。生成AIという技術革新の時代に生まれたことに改めて高揚感が高まっています。また、多くの企業がAWSを活用して次々と革新的なソリューションを生み出している様子を目の当たりにし、そのエネルギーを肌で感じることができました。 AWS Summit Japanは、素晴らしい学びを提供し、多くの人々にインスピレーションと知見を与える有意義な場でした。これからもAWSへの学びを深めていきたいです！ 来年のAWS Summit開催を楽しみに待ちたいと思います！

こんにちは、広野です。 本題だけ挨拶抜きで冒頭に話します。本記事では、Amazon API Gateway と Amazon SES を Lambda 抜きで 連携する方法を紹介します。 はじめに 先月、AWS Summit Japan 2024 が開催されました。その中で、印象に残った AWS さんのセッションがありました。 「サーバーレス開発のベストプラクティス～より効果的に、より賢く使いこなすために～」 このセッションでは、サーバーレス開発のアーキテクチャ事例を数多く紹介してくれて非常に有用だったのですが、特に印象に残ったのは 「 AWS サービス間をプロキシするだけの Lambda 使用はやめましょう 」 というようなメッセージでした。 常々、私はサーバーレス開発において、コードやランタイムのメンテが必要になる AWS Lambda 関数が乱立することを負担に感じていました。また、昨今のアーキテクチャ時流では AWS Step Functions が AWS サービスの API を直接叩けるようになったり、Amazon EventBridge を活用したサービス間連携アーキテクチャの台頭があったりして、「とりあえず Lambda」から「脱 Lambda」に変わってきています。 そういう意味で、このメッセージには非常に共感を持つことができました。セッションでは Amazon API Gateway から 他の AWS サービスの連携も Lambda 関数抜きで行うアーキテクチャを紹介しており、やってみたくなりました。 私が題材に選んだのは、 Amazon API Gateway と Amazon SES の直接連携 です。現在主流のアーキテクチャでは、メールを送信する AWS Lambda 関数がメールのコンテンツを加工し、Amazon SES の API を叩く役割を持っています。しかしながら、加工と言っても文字列をちょこっといじるだけのようなもので、何らビジネスロジックがないケースが多いのではないかと思います。であれば、AWS Lambda 関数はいらんだろう！ということでチャレンジしたくなりました。 やりたいこと 本記事で紹介するアーキテクチャは、以前 jQuery でメール送信 API を叩くアーキテクチャを紹介した記事をベースにしています。その記事ではメール送信 API を Amazon API Gateway + AWS Lambda + Amazon SES で作成していたので、そこから Lambda を抜く！部分にフォーカスして執筆いたします。 ベースとなるアーキテクチャ、技術情報は以下リンクをご覧下さい。 フリーの HTML テンプレートと AWS を使って問い合わせフォーム付きサーバーレス WEB サイトをつくってみよう 本記事では、静的WEBサイトに jQuery で動的な機能を付加する例を紹介します。 blog.usize-tech.com 2022.07.14 前回記事の構成から Amazon API Gateway REST API は Amazon SES との直接連携をサポートしている。統合タイプの設定は AWS を選択する。 公開 WEB サイトの問い合わせフォームで使用するため、ユーザ認証はない。CORS はある。 CORS でハマるのが嫌なので、AWS CloudFormation でデプロイする。 WEB サイトから送信するデータは以下の JSON フォーマットとなっている。 { "subj": "件名", "name": "名前", "email": "xxx@xxxxxxx.com", "body": "問い合わせメッセージ本文" } 従来、このデータを AWS Lambda 関数にパススルーして、文字列加工したデータを Amazon SES に渡していた。AWS Lambda 関数がやっていたことは Amazon API Gateway REST API の「統合リクエスト」内、「マッピングテンプレート」で肩代わりさせる。 マッピングテンプレートは VTL (Velocity Template Language) で定義する。(AWS AppSync では多用するので AppSync 信者にはお馴染み) Amazon SES の API は SendEmail を使用する。 マッピングテンプレートをどう書くか AWS Lambda 関数でやっていたことを Amazon API Gateway のマッピングテンプレートに肩代わりさせるので、そこが肝になります。イメージしてもらいやすくするため、AWS Lambda 関数と対比して紹介します。 AWS Lambda 関数 細かい違いはあれど、だいたい以下のような AWS Lambda 関数 (Python) で Amazon SES を呼び出すと思います。 import json import datetime import boto3 def datetimeconverter(o): if isinstance(o, datetime.datetime): return str(o) def lambda_handler(event, context): try: # Define Variables ses = boto3.client('ses',region_name='ap-northeast-1') d = json.loads(event['body']) print({"ReceivedData": d}) RECEIVERS = [] RECEIVERS.append('xxxxx@xxxxxxx.xxxx') SENDER = 'xxxxxx@xxxxx.xxxxxx' # Send Email res = ses.send_email( Destination={ 'ToAddresses': RECEIVERS }, Message={ 'Body': { 'Text': { 'Charset': 'UTF-8', 'Data': 'NAME: ' + d['name'] + '\nMAILADDRESS: ' + d['email'] + '\n\nMESSAGE:\n' + d['body'] } }, 'Subject': { 'Charset': 'UTF-8', 'Data': d['subj'] } }, Source=SENDER, ReplyToAddresses=[d['email']] ) except Exception as e: print(e) return { 'isBase64Encoded': False, 'statusCode': 200, 'body': str(e) } else: return { 'isBase64Encoded': False, 'statusCode': 200, 'body': json.dumps(res, indent=4, default=datetimeconverter) } マッピングテンプレート マッピングテンプレートだと、以下のようになります。 ## API Gateway が受け取った引数を $inputRoot に格納する #set($inputRoot = $input.path('$')) ## メール本文の文字列加工 改行を入れたければここでリアルに改行すればよい(かなり違和感を感じるw) #set($tempbodya = "NAME: $inputRoot.name MAILADDRESS: $inputRoot.email MESSAGE: $inputRoot.body") ## Windows 環境からだと改行コードが CRLF で来ることがあるので、LF に置換しておく #set($tempbodyb = $tempbodya.replaceAll("\r\n", "\n")) ## メール本文は URL エンコードすること #set($body = $util.urlEncode($tempbodyb)) ## メールアドレスは URL エンコードすること #set($destination = $util.urlEncode("xxxxx@xxxxx.xxx")) #set($replyto = $util.urlEncode($inputRoot.email)) #set($source = $util.urlEncode("xxxxx@xxxxxx.xxxx")) ## 件名はエンコードしなくてよい、なぜか。エンコードするとエラーになる。改行が入っても通った。謎。 #set($subject = $inputRoot.subj) ## SES API 呼出はこのフォーマットで書く URL の続きに?付きでパラメータ指定するのと同じ形式 Action=SendEmail&Destination.ToAddresses.member.1=$destination&Message.Body.Text.Data=$body&Message.Subject.Data=$subject&ReplyToAddresses.member.1=$replyto&Source=$source AWS Lambda 関数では、URL エンコードなんて一切意識していなかったと思います。AWS が提供してくれる SDK がいい感じにデータを加工してくれていたものと思います。VTL は低級言語？なのか SDK をロードできないですし、組み込み関数も少ないです。ただ URL エンコードする関数 ($util.urlEncode) は用意してくれているので助かりました。 URL エンコードが必要な理由は、マッピングテンプレートから Amazon SES SendEmail API を呼び出すときに API の URL に続けてパラメータを書いて渡すためです。(想像) URL には使用してはいけない文字列、記号があり、UTF-8 の文字コードの文字列を URL で使用できる文字列、記号の範囲内におさまるようにエンコードする必要があります。それが URL エンコードです。 例えば、メールアドレスの @ は使えませんし、改行、日本語なんてもってのほかです。@ は %40 に、改行(\n) は %3A に置き換えられます。 メールの To だけでなく、Cc、Bcc ももちろん設定可能です。これらは複数指定できますが、仕様でそれぞれ 50 個までしか指定できません。To を複数指定するときは、Destination.ToAddress.member.1= のような記述を1始まりで50まで羅列させます。配列が使用できないので、このような書き方になります。AWS Lambda 関数では配列で SDK に渡していたので意識しなかった部分です。 VTL ではダブルクォーテーションとシングルクォーテーションで動きが異なるので、このサンプルコードにあるクォーテーションのまま使用することをお勧めします。 ここまで動く状態に到達するのに、情報が少なくて結構苦労しました。 他にも Amazon API Gateway の設定はあるのですが、メインはマッピングテンプレートでしたので、AWS CloudFormation テンプレートのところで補足いたします。 実際の動作 WEB サイトの問い合わせフォームから、問い合わせを送信します。 こんなメールが予め設定しておいた送信先メールアドレスに届きます。 AWS CloudFormation テンプレート 前回記事で紹介した AWS CloudFormation を修正したものを貼り付けます。一式、Amazon CloudFront や Amazon S3 なども含まれています。一応執筆時点で動いたことは確認済みです。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates a static website hosting environment with a backend API for receiving emails from feedback form. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SiteName: Type: String Description: Your Site name. (Not any upper case characters) Default: xxxxx MaxLength: 40 MinLength: 1 DomainName: Type: String Description: Domain name for URL. Default: example.com MaxLength: 100 MinLength: 5 AllowedPattern: "([a-zA-Z0-9][a-zA-Z0-9-]*[a-zA-Z0-9]*\\.)+[a-zA-Z]{2,}" SubDomainName: Type: String Description: Sub domain name for URL. Default: xxxxx MaxLength: 20 MinLength: 1 FeedbackSenderEmail: Type: String Description: E-mail address that sends feedback emails. Default: sender@example.com MaxLength: 100 MinLength: 5 AllowedPattern: "[a-zA-Z0-9_+-]+(.[a-zA-Z0-9_+-]+)*@([a-zA-Z0-9][a-zA-Z0-9-]*[a-zA-Z0-9]*\\.)+[a-zA-Z]{2,}" FeedbackReceiverEmail: Type: String Description: E-mail address that receives feedback emails. Default: receiver@example.com MaxLength: 100 MinLength: 5 AllowedPattern: "[a-zA-Z0-9_+-]+(.[a-zA-Z0-9_+-]+)*@([a-zA-Z0-9][a-zA-Z0-9-]*[a-zA-Z0-9]*\\.)+[a-zA-Z]{2,}" CertificateId: Type: String Description: ACM certificate ID. CloudFront only supports ACM certificates in us-east-1 region. Default: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx MaxLength: 36 MinLength: 36 Resources: # ------------------------------------------------------------# # S3 # ------------------------------------------------------------# S3Bucket: Type: AWS::S3::Bucket Properties: BucketName: !Sub website-${SiteName} PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true Tags: - Key: Cost Value: !Sub website-${SiteName} S3BucketPolicy: Type: AWS::S3::BucketPolicy Properties: Bucket: !Ref S3Bucket PolicyDocument: Version: "2012-10-17" Statement: - Action: - "s3:GetObject" Effect: Allow Resource: !Sub "arn:aws:s3:::${S3Bucket}/*" Principal: Service: cloudfront.amazonaws.com Condition: StringEquals: AWS:SourceArn: !Sub arn:aws:cloudfront::${AWS::AccountId}:distribution/${CloudFrontDistribution} DependsOn: - S3Bucket - CloudFrontDistribution # ------------------------------------------------------------# # CloudFront # ------------------------------------------------------------# CloudFrontDistribution: Type: AWS::CloudFront::Distribution Properties: DistributionConfig: Enabled: true Comment: !Sub CloudFront distribution for website-${SiteName} Aliases: - !Sub ${SubDomainName}.${DomainName} HttpVersion: http2 IPV6Enabled: true PriceClass: PriceClass_200 DefaultCacheBehavior: TargetOriginId: !Sub S3Origin-website-${SiteName} ViewerProtocolPolicy: redirect-to-https AllowedMethods: - GET - HEAD - OPTIONS CachedMethods: - GET - HEAD CachePolicyId: !Ref CloudFrontCachePolicy OriginRequestPolicyId: !Ref CloudFrontOriginRequestPolicy ResponseHeadersPolicyId: !Ref CloudFrontResponseHeadersPolicy Compress: true SmoothStreaming: false DefaultRootObject: index.html CustomErrorResponses: - ErrorCachingMinTTL: 10 ErrorCode: 403 ResponseCode: 404 ResponsePagePath: /404.html Origins: - Id: !Sub S3Origin-website-${SiteName} DomainName: !Sub ${S3Bucket}.s3.${AWS::Region}.amazonaws.com OriginAccessControlId: !GetAtt CloudFrontOriginAccessControl.Id S3OriginConfig: OriginAccessIdentity: "" ConnectionAttempts: 3 ConnectionTimeout: 10 ViewerCertificate: AcmCertificateArn: !Sub "arn:aws:acm:us-east-1:${AWS::AccountId}:certificate/${CertificateId}" MinimumProtocolVersion: TLSv1.2_2021 SslSupportMethod: sni-only Tags: - Key: Cost Value: !Sub website-${SiteName} DependsOn: - CloudFrontCachePolicy - CloudFrontOriginRequestPolicy - CloudFrontResponseHeadersPolicy - CloudFrontOriginAccessControl - S3Bucket CloudFrontOriginAccessControl: Type: AWS::CloudFront::OriginAccessControl Properties: OriginAccessControlConfig: Description: !Sub CloudFront OAC for website-${SiteName} Name: !Sub OriginAccessControl-website-${SiteName} OriginAccessControlOriginType: s3 SigningBehavior: always SigningProtocol: sigv4 CloudFrontCachePolicy: Type: AWS::CloudFront::CachePolicy Properties: CachePolicyConfig: Name: !Sub CachePolicy-website-${SiteName} Comment: !Sub CloudFront Cache Policy for website-${SiteName} DefaultTTL: 3600 MaxTTL: 86400 MinTTL: 60 ParametersInCacheKeyAndForwardedToOrigin: CookiesConfig: CookieBehavior: none EnableAcceptEncodingBrotli: true EnableAcceptEncodingGzip: true HeadersConfig: HeaderBehavior: whitelist Headers: - Access-Control-Request-Headers - Access-Control-Request-Method - Origin QueryStringsConfig: QueryStringBehavior: none CloudFrontOriginRequestPolicy: Type: AWS::CloudFront::OriginRequestPolicy Properties: OriginRequestPolicyConfig: Name: !Sub OriginRequestPolicy-website-${SiteName} Comment: !Sub CloudFront Origin Request Policy for website-${SiteName} CookiesConfig: CookieBehavior: none HeadersConfig: HeaderBehavior: whitelist Headers: - Access-Control-Request-Headers - Access-Control-Request-Method - Origin QueryStringsConfig: QueryStringBehavior: none CloudFrontResponseHeadersPolicy: Type: AWS::CloudFront::ResponseHeadersPolicy Properties: ResponseHeadersPolicyConfig: Name: !Sub ResponseHeadersPolicy-website-${SiteName} Comment: !Sub CloudFront Response Headers Policy for website-${SiteName} SecurityHeadersConfig: ContentSecurityPolicy: ContentSecurityPolicy: !Sub >- default-src 'self' *.${DomainName}; img-src 'self' *.${DomainName} data: blob:; style-src 'self' *.${DomainName} fonts.googleapis.com; font-src 'self' *.${DomainName} fonts.gstatic.com; script-src 'self' *.${DomainName} 'unsafe-inline'; script-src-elem 'self' *.${DomainName}; connect-src 'self' *.${DomainName} *.amazonaws.com; Override: true ContentTypeOptions: Override: true FrameOptions: FrameOption: DENY Override: true ReferrerPolicy: Override: true ReferrerPolicy: strict-origin-when-cross-origin StrictTransportSecurity: AccessControlMaxAgeSec: 31536000 IncludeSubdomains: true Override: true Preload: true XSSProtection: ModeBlock: true Override: true Protection: true CustomHeadersConfig: Items: - Header: Cache-Control Value: no-store Override: true # ------------------------------------------------------------# # Route 53 # ------------------------------------------------------------# Route53RecordIpv4: Type: AWS::Route53::RecordSet Properties: HostedZoneName: !Sub ${DomainName}. Name: !Sub ${SubDomainName}.${DomainName}. Type: A AliasTarget: HostedZoneId: Z2FDTNDATAQYW2 DNSName: !GetAtt CloudFrontDistribution.DomainName DependsOn: - CloudFrontDistribution Route53RecordIpv6: Type: AWS::Route53::RecordSet Properties: HostedZoneName: !Sub ${DomainName}. Name: !Sub ${SubDomainName}.${DomainName}. Type: AAAA AliasTarget: HostedZoneId: Z2FDTNDATAQYW2 DNSName: !GetAtt CloudFrontDistribution.DomainName DependsOn: - CloudFrontDistribution # ------------------------------------------------------------# # API Gateway # ------------------------------------------------------------# RestApiSendEmail: Type: AWS::ApiGateway::RestApi Properties: Name: !Sub SendEmail-website-${SiteName} Description: !Sub REST API to send user's feedback email for website-${SiteName} EndpointConfiguration: Types: - REGIONAL Tags: - Key: Cost Value: !Sub website-${SiteName} RestApiDeploymentSendEmail: Type: AWS::ApiGateway::Deployment Properties: RestApiId: !Ref RestApiSendEmail DependsOn: - RestApiMethodSendEmailPost - RestApiMethodSendEmailOptions RestApiStageSendEmail: Type: AWS::ApiGateway::Stage Properties: StageName: prod Description: production stage RestApiId: !Ref RestApiSendEmail DeploymentId: !Ref RestApiDeploymentSendEmail MethodSettings: - ResourcePath: "/*" HttpMethod: "*" LoggingLevel: INFO DataTraceEnabled : true TracingEnabled: false Tags: - Key: Cost Value: !Sub website-${SiteName} RestApiResourceSendEmail: Type: AWS::ApiGateway::Resource Properties: RestApiId: !Ref RestApiSendEmail ParentId: !GetAtt RestApiSendEmail.RootResourceId PathPart: sendemail RestApiMethodSendEmailPost: Type: AWS::ApiGateway::Method Properties: RestApiId: !Ref RestApiSendEmail ResourceId: !Ref RestApiResourceSendEmail HttpMethod: POST AuthorizationType: NONE Integration: Type: AWS IntegrationHttpMethod: POST Credentials: !GetAtt ApigSesInvocationRole.Arn Uri: !Sub arn:aws:apigateway:${AWS::Region}:email:action/SendEmail PassthroughBehavior: WHEN_NO_TEMPLATES RequestParameters: integration.request.header.Content-Type: "'application/x-www-form-urlencoded'" RequestTemplates: application/json: !Sub - |- #set($inputRoot = $input.path('$')) #set($tempbodya = "NAME: $inputRoot.name MAILADDRESS: $inputRoot.email MESSAGE: $inputRoot.body") #set($tempbodyb = $tempbodya.replaceAll("\r\n", "\n")) #set($body = $util.urlEncode($tempbodyb)) #set($destination = $util.urlEncode("${FeedbackReceiverEmail}")) #set($replyto = $util.urlEncode($inputRoot.email)) #set($subject = $inputRoot.subj+"(${SubDomainName}.${DomainName})") #set($source = $util.urlEncode("${FeedbackSenderEmail}")) Action=SendEmail&Destination.ToAddresses.member.1=$destination&Message.Body.Text.Data=$body&Message.Subject.Data=$subject&ReplyToAddresses.member.1=$replyto&Source=$source - {} IntegrationResponses: - StatusCode: 200 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" - StatusCode: 400 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" - StatusCode: 403 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" - StatusCode: 404 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" - StatusCode: 500 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" - StatusCode: 503 ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" MethodResponses: - StatusCode: 200 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 400 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 403 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 404 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 500 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true - StatusCode: 503 ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Origin: true method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true RestApiRequestModelSendEmail: Type: AWS::ApiGateway::Model Properties: ContentType: application/json RestApiId: !Ref RestApiSendEmail Schema: |- { "$schema": "http://json-schema.org/draft-04/schema#", "title": "SendEmail", "type": "object", "properties": { "subj": { "type": "string" }, "name": { "type": "string" }, "email": { "type": "string" }, "body": { "type": "string" } }, "required": ["subj", "name", "email", "body"] } RestApiMethodSendEmailOptions: Type: AWS::ApiGateway::Method Properties: RestApiId: !Ref RestApiSendEmail ResourceId: !Ref RestApiResourceSendEmail HttpMethod: OPTIONS AuthorizationType: NONE Integration: Type: MOCK Credentials: !GetAtt ApigSesInvocationRole.Arn IntegrationResponses: - ResponseParameters: method.response.header.Access-Control-Allow-Headers: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,Cache-Control'" method.response.header.Access-Control-Allow-Methods: "'POST,OPTIONS'" method.response.header.Access-Control-Allow-Origin: !Sub "'https://${SubDomainName}.${DomainName}'" ResponseTemplates: application/json: '' StatusCode: 200 PassthroughBehavior: WHEN_NO_MATCH RequestTemplates: application/json: '{"statusCode": 200}' MethodResponses: - ResponseModels: application/json: Empty ResponseParameters: method.response.header.Access-Control-Allow-Headers: true method.response.header.Access-Control-Allow-Methods: true method.response.header.Access-Control-Allow-Origin: true StatusCode: 200 # ------------------------------------------------------------# # API Gateway SES Invocation Role (IAM) # ------------------------------------------------------------# ApigSesInvocationRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ApigSesInvocationRole-website-${SiteName} Description: This role allows API Gateways to invoke SES. AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - apigateway.amazonaws.com Action: - sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess Policies: - PolicyName: !Sub ApigSesInvocationPolicy-website-${SiteName} PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - "ses:SendEmail" Resource: - "*" # ------------------------------------------------------------# # Output Parameters # ------------------------------------------------------------# Outputs: APIGatewayEndpointSendEmail: Value: !Sub https://${RestApiSendEmail}.execute-api.${AWS::Region}.${AWS::URLSuffix}/${RestApiStageSendEmail}/sendemail SiteURL: Value: !Sub https://${SubDomainName}.${DomainName} Amazon API Gateway を CORS 対応にしているので、レスポンスのところで CORS 関連の設定が多くなっています。ヘッダー関連の設定はあまりいじらない方がよいと思います。 統合リクエストの設定で、HTTP ヘッダーに Content-Type: ‘application/x-www-form-urlencoded’ を設定しています。こうしないと動きませんでした。 このテンプレートが動作する前提はいろいろあるのですが (すいません) 前回記事から追加していることだけ。Amazon API Gateway のログを Amazon CloudWatch Logs に push するために必要な IAM ロールがアカウントに登録済みでないとエラーになります。それについては以下の記事をご確認ください。 Amazon API Gateway のログを Amazon CloudWatch Logs に書き込むための IAM ロールはアカウント単位の設定です Amazon API Gateway のログを Amazon CloudWatch Logs に書き込むための IAM ロール設定を紹介します。 blog.usize-tech.com 2024.07.01 まとめ いかがでしたでしょうか？ 正直に申しますと、意気込んでやってはみたものの、 AWS Lambda 関数抜きの Amazon SES SendEmail API 呼出は絶対に流行らない と確信しました。VTL の使い勝手が Python に比べて悪すぎるのと、SendEmail 呼出だと文字列のエンコードというデリケートな部分があるためです。気を遣わなくて済む AWS Lambda の方が楽です。でも、せっかく作ったので私はこの方法を使おうと思います。他人にはお勧めしませんが。w ですがこの例は、Amazon API Gateway から Amazon SES でない、他の AWS サービスへの直接連携の参考になるかもしれません。 本記事が皆様のお役に立てれば幸いです。 最後に補足です。Amazon SES からメール送信するときは、Gmail と Yahoo Mail が実装した送信者要件を満たさないとそれらにはメールが届かない恐れがあります。Amazon SES 側で必要な設定があるので、要注意です。私も実装しました。 Yahoo/Gmail におけるメールの一括送信者に求められる要件の変更について | Amazon Web Services Gmail と Yahoo Mail は、ユーザーの受信トレイを保護するための取り組みとして、2024 年 2 月から送信者に関する新たな要件を発表しました。これらの要件を満たすために Amazon Simple Email Service... aws.amazon.com

こんにちは。SCSK渡辺(大)です。 AWS初心者なので、AWS Summit Japan 2024 は異世界に転生したような気持ちで楽しむことが出来ました。 今回は、 Amazon EC2 のコスト効率化に関する推奨事項を提供するサービス   を整理してみました。 そろそろ夏なので、熱中症にならないように暑苦しいコストは削っていきましょう。 ※当記事では、Amazon EC2 インスタンス ＝ EC2 としています。 EC2のコストを削減する方法 まずはじめに、EC2のコストを削減する方法を考えてみます。 無駄な待機課金をなくすために、稼働スケジュールを見直す。 コストを抑えて利用するために、Reserved Instances/Savings Plans（RI/SP）を購入する。 最適な使用率にするために、インスタンスサイズを小さくする。   推奨事項を確認できるサービスとコスト削減方法の関係性 推奨事項を確認できるサービスとコスト削減方法の関係性は次の通りです。 推奨事項を確認できるサービス 関連するコスト削減方法 Trusted adviser a,b Compute Optimizer c Billing and Cost Management サイズ適正化に関する推奨事項 c Cost Optimization Hub a,b,c Reserved Instances b Savings Plans b   注意点 すべての推奨事項を実施したとしても、すべての恩恵を受けることが出来るわけではありません。 勘違いしたままだと「思ってた効果が得られなかった！」と悲しい思いをします。 なぜそのようなことになるのか？ 理由は２つあります。 各サービスの推奨事項は競合します。 理由は言葉にすると難しいので、イメージ図を参照ください。 なお、Cost Optimization Hubは敢えて図に入れていません。   確認する日によって推奨事項の内容は変わります。 理由は単純で、ルックバック期間がズレるためです。 ルックバック期間とは”過去のデータを何日前まで遡って推奨事項を出すかを決める期間”です。 イメージ図はルックバック期間が60日間の場合です。   おすすめのロードマップ では、どうしたら良いか？ 次のように段階を踏んでいくことで効率良くコスト削減できるかと思います。 （あくまで自論です。コスト削減に答えはありません！） RI/SP購入 まずは推定削減額の大きいものから実施します。 ただし、RI/SPの購入しすぎは効果が不明瞭になったり、 アカウントを解約したいのに有効期限前のRI/SPが大量に残ったりするリスクがありますので、 1年後や3年後の利用状況を見据えて計画することが重要です。 Trusted adviseやCompute Optimizerの設定見直し ルックバック期間などの設定を見直し、推奨事項の精度を向上させます。 推奨事項の再確認 見直した設定が反映され、競合が収まる頃（RI/SP購入から3か月ほど経過した後）に再確認します。 その中から簡単に実施出来る推奨事項を実施します。 継続的なコスト削減の運用化 1と3を繰り返し継続的なコスト削減を図ります。 また、必要に応じて、2の設定見直しも実施します。   EC2のコスト効率化に関する推奨事項を提供するサービス 続いて、EC2のコスト効率化に関する推奨事項を提供するサービスを見てみましょう。 なお、当記事ではサービスの概要と確認画面にフォーカスし、推奨事項の細かい説明は煩雑になるため割愛します。 Trusted adviser 各種リソースのベストプラクティスを支援してくれるサービスです。 AWS自体の知見と利用状況を組み合わせて分析してコスト最適化の推奨事項を提案してくれます。 コスト最適化の他にも、パフォーマンスやセキュリティなどの最適化の観点で推奨事項を提案してくれます。 推奨事項は次の画面から確認することができます。 Trusted adviser　＞　コスト最適化　＞　「即時の対応が推奨されるアクション」または「調査が推奨されます」を選択 Compute Optimizer 各種リソースの最適化に関する推奨事項を提案してくれるサービスです。 CPU使用率などのメトリクスを分析してコスト最適化の推奨事項を提案してくれます。 推奨事項は次の画面から確認することができます。 Compute Optimizer　＞　ダッシュボード 下にスクロールします。 EC2 インスタンス　＞　過剰なプロビジョニング Billing and Cost Management Billing and Cost Management は請求とコストの最適化に役立つ機能を提供するサービスです。 利用状況を分析してコスト最適化の推奨事項を提案してくれます。 サイズ適正化に関する推奨事項 こちらはレガシーページのためAWS推奨ではありませんが、2024年7月時点でまだ確認できるためご紹介します。 推奨事項は次の画面から確認することができます。 Billing and Cost Management　＞　レガシーページ　＞　規模の適正化　＞　サイズの適正化に関する推奨事項   Cost Optimization Hub Cost Optimization HubはAWS推奨です。 Compute Optimizerなどの推奨事項を一元化してくれます。 つまり、「各サービスの推奨事項は競合します。」という注意点は、このサービスが解消してくれます。 「じゃあ、これだけ見れば良くないか？」と思うかもしれませんが、全てのリソースをサポートしているわけではありません。 ですので、他のサービスと併せて確認するのが良いかと思います。 なお、”サポートされているリソース”については、 ユーザーガイド をご確認ください。 推奨事項は次の画面から確認することができます。 Billing and Cost Management　＞　コスト最適化ハブ Reserved Instances 推奨事項は次の画面から確認することができます。 Billing and Cost Management　＞　予約　＞　推奨事項 Savings Plans 推奨事項は次の画面から確認することができます。 Billing and Cost Management　＞　Savings Plans　＞　推奨事項 まとめ お手軽にコスト削減の推奨事項を確認したい場合は、Cost Optimization Hubだけを確認することをオススメします。 全ての無駄コストを根絶やしにしたい場合は、その他のサービスの推奨事項も確認する必要があります。 当記事では推奨事項の細かい説明は割愛してしまったので、物足りない方は「AWS EC2 コスト最適化」で検索してみてください！ AWS EC2 コスト最適化 検索

こんにちは。SCSKの田中です。 本記事では、ランサムウェア対策の最後の砦ともいえるバックアップの重要性やポイントについてご紹介します。 なお本投稿の前段にあたる投稿は以下のリンクよりご覧いただけます。 「ランサムウェアに気をつけろ！基礎知識と安全対策のポイント」 また、USiZEでは新たにオプションサービス：ランサムウェア対応サービスをリリースいたしました。 USiZE、ランサムウェア対応サービスにご興味を持っていただけた方は、以下ページをご参照ください。 USiZEについて ランサムウェア対応サービスに関するプレスリリース ランサムウェアの脅威 最近、人気動画サイトが被害を受けたことで話題となったように、ランサムウェアによる脅威が企業を脅かしています。 VPN機器の脆弱性やRDP通信の認証情報を悪用して、システム全体に攻撃が広がり、甚大な被害を及ぼしています。 以下はシステム全体に被害が拡大した事例です。 どちらもシステムが停止し、事業継続に大きな影響を与えました。 事例1：名古屋港のコンテナターミナルシステムの事例 　 ・ 感染経路 　 　　VPN 機器からの侵入が行われたと考えられている ​ 　・被害 　　　・ 物理サーバ8台、および全仮想サーバ45台が暗号化されました。 　　　・ システムが停止し、約3日間コンテナ搬出・搬入業務が停止しました。 事例2： ​ 大阪急性期・総合医療センター 　・ 感染経路 　　　給食事業者が設置するシステムにVPN機器から侵入が行われ、窃取された認証情報によりRDP通信を用いて、 　　　病院給食サーバに侵入しました。そして病院給食サーバを踏み台に、他サーバへも被害が拡大 　・ 被害 　　　・ 基幹システムサーバの大部分が暗号化、電子カルテシステムが暗号化された影響で長期間診療制限​ 　　　・ 基幹システムが再稼働するまで43日間、部門システムを含めた全体の診療システム復旧は73日間 また「Ransomeware as a Service(RaaS)」というランサムウェアの機能を提供するサービスが 名古屋港へのサイバー攻撃者として報道が多く出回っている「LockBit」も、その一例です。 LockBitが攻撃者から支持を受けている理由は「ユーザーフレンドリーなインターフェイス」により、 簡単に攻撃プログラムを組み立てることができる点にあると言われています。 これにより、高度な知識や専門的な技術を持たない人間でもランサムウェア攻撃が可能となっています。 このような背景から、ランサムウェアによる被害は今後ますます増加すると考えられます。                  バックアップデータが最後の砦に!! ランサムウェアからの攻撃を100%防御することは非常に困難です。 境界型防御やセキュリティ対策ソフトをすり抜ける事例も報告されています。​ 万が一攻撃を受けた際も、バックアップデータが無事であればデータを復旧することが可能です。 そのため、バックアップは最後の砦といえる対策となっています。                       バックアップが攻撃の対象に! ただバックアップを取っておくだけでは安全とはいえません。​ 攻撃者も容易に復旧されないようにバックアップデータを標的とします。 例えば、以下のような手法で攻撃が行われることがあります。 ・ バックアップデータ自体が暗号化される。 ・ バックアップデータが削除される。 ・バックアップソフトウェアがアンインストールされる そのため、バックアップデータを保護するための仕組みが必要となります。 仕組み①：侵入されにくいOS バックアップ製品に対してOSレイヤーで侵入される危険性があります。 WindowsやLinuxといったシェア率の高いOSは、情報が広く流布しているため、 攻撃者にとっても攻撃のための情報が集めやすいです。 それに比べ、独自OSは攻撃のための情報が限られているため、攻撃の難易度が高くなっています 仕組み②：書き換え不可なバックアップデータ バックアップデータ自体が上書きされることを防止するために、バックアップデータを書き換え不可にする機能が必要です。 イミュータブルバックアップ機能やWORM機能と呼ばれています。 他にもアクセス不可な領域に保管するエアギャップ、管理ツールの多要素認証などがあげられます。 またバックアップ製品の機能だけでなく、自社で気を付ける方法として「3-2-1ルール」に則るなどの対策も有効です。 3-2-1ルール ルール① ： データは少なくとも「3つ」のバックアップコピーを持つ ルール② ： バックアップデータを「2種類」以上の異なる媒体に保存する ルール③ ： データ保管先のうち「1つ」は物理的所在地が遠隔地にあるものを選定   復旧時にバックアップデータを利用可能か? データのバックアップを取っているだけでは、破壊されたデータやマルウェアが潜むデータは復旧に利用できません。 そのため、復旧する際にはランサムウェアによる攻撃を受けていない安全なバックアップデータを特定する必要があります。 しかし、保持しているバックアップの世代数が多いほど、安全なバックアップデータを特定するのに時間がかかることがあります。 以下の図では8日分のバックアップしか保持していないため、5世代分のバックアップデータを調査することで 安全なバックアップデータの特定が可能ですが、場合によっては数か月前のデータにさかのぼっての確認が必要となります。                     そのため、バックアップデータが安全であることを確認するための機能が重要です。 最近のバックアップ製品にはAIなどを活用し、異常を検知する機能が搭載されています。 検知機能を利用することで調査対象を絞り込むことができ、特定までにかかる時間を短縮することが可能です。 USiZE バックアップ・ランサムウェア対応サービスのご紹介 最後にUSiZE バックアップ・ランサムウェア対応サービスのご紹介です。 USiZEではランサムウェア攻撃に備えたバックアップ・オプションサービスのランサムウェア対応サービスがございます。 バックアップデータ保護の仕組み USiZE 標準バックアップは独自OSや上書きや削除が不可能なイミュータブルファイルシステムという仕組みがあります。 他にも管理ツールは多要素認証によるなりすまし防止やSMB/NFSといった汎用的なアクセス方式の 制限など様々な仕組みによりバックアップデータを保護しています。 事業復旧対応を支援するランサムウェア対応サービス ランサムウェア対応サービスでは、ランサムウェアにより攻撃された疑いを機械学習により検知します。 「バックアップ侵害検知」では、ランサムウェアによる攻撃された疑いを検知すると自動で電話およびメールにて通知します。 「バックアップ保持・仮想マシン隔離」では、ランサムウェアによる攻撃された疑いを検知した際に自動で以下の2つの対応をいたします。 バックアップ保持： 　以降のバックアップジョブが実行されないように自動で一時停止を行い、破壊されたデータのバックアップ取得や 世代管理のため、バックアップデータが削除されることを防止します。 仮想マシン隔離： 　仮想マシンの仮想NICを自動で遮断し、感染拡大を防止します。 バックアップ侵害検知は5月にリリースしています。 バックアップ保持・仮想マシン隔離は近日中にリリースいたします。 USiZEやランサムウェア対応サービスについてご興味をお持ちになりましたら、気軽にお問合せください。 　宛先： SCSK 株式会社 USiZE サービス部 ​ 　メールアドレス： usize-info@scsk.jp バックアップシステムの導入等にお困りの方はぜひ以下の記事についてもご参照ください。 バックアップ導入の勘所 参考資料 国土交通省 「コンテナターミナルにおける情報セキュリティ対策等検討委員会中間取りまとめ①名古屋港のコンテナターミナルにおけるシステム障害を踏まえ緊急に実施すべき対応策について（案） 」 大阪急性期・総合医療センター 「大阪急性期・総合医療センター 情報セキュリティインシデント調査報告書 概要」 トレンドマイクロ株式会社 RaaS (Ransomware as a Service)とは

本記事はBackhaulingの 「 Internet Breakout 」についてのご紹介です。 Local gateway IPについては、前編をご参照ください。 【前編】CatoクラウドのBackhaulingについて～Local gateway IP～ Catoクラウドの「Backhauling」をご紹介します！Backhaulingには2種類ありますが、今回は「Local gateway IP」のご紹介です。 blog.usize-tech.com 2024.06.26 「Internet Breakout」の ユースケース ※本記事では「Internet Breakout」のユースケースの一例をご紹介します。 Backhaulingの「Internet Breakout」は主に「一部トラフィックのみ、CatoのPoPのアドレスでアクセスさせたくない」場合に利用します。 具体的にユースケースを2つ挙げてご説明していきます。 SaaSサービス側で固定されている送信元アドレスを CatoのPoPのアドレスに 変更できない場合 SaaSサービスを各社専用のグローバルアドレスでアクセス制限をかけて利用している場合を考えてみます。 この場合、 Catoクラウド経由でアクセスさせるためには SaaSサービス側で送信元アドレスをCatoクラウドのPoPのアドレスに変更する必要がありますが、何らかの理由で変更ができないケースもあるかと思います。 そんな時、Backhaulingを使えば Catoクラウドを経由しながら現行 の グローバルアドレスを使ってアクセスさせることができます。 ＝  特定のWebサイトに、 CatoのPoPのアドレス でアクセスできない場合 Cato PoPのIPアドレスは、JPNICでなく上位のAPNICからIPアドレスを取得しています。 そのためアクセス先のWebサイトが日本からのアクセスのみに制限をかけている場合、Catoクラウド経由でアクセスできないケースがあります。 こんな時も、Backhaulingを使えば Catoクラウドを経由しながらISPの グローバルアドレスを使ってアクセスさせることができます。 “Catoクラウドを経由しながら”とはどういうことか構成図を使って補足します。 (前編を見たので説明不要という方は飛ばしてください） 例えば下図の構成の場合、 支店のユーザやモバイルユーザから宛先へのトラフィックは赤線経路で一度Catoクラウドを経由します。 その後、 トラフィックは 本社 内のSocketに転送され本社のインターネット回線経由でアクセスさせるといった通信経路です。 ここで注目いただきたいのは、 宛先が ドメイン・アプリケーションに加え、 IPアドレス・FQDN等の様々な形で指定することができる という点です。 Catoクラウドのその他機能には宛先をアプリケーションでしか指定できないものもあります。 それらの機能と比較すると設定方法においては便利であると言えるんです！（例えば、Split TunnelやBypass等の場合、宛先はアプリケーション指定のみです。※2024年6月現在） 「Internet Breakout」の設定例 前編でもお伝えした通り、 Backhaulさせたトラフィックは一度、Catoクラウドを経由 します 。 そのため、Catoクラウドのセキュリティチェックが適用され、ログにも記録されます。 ということで、以下3点を確認するためテストを行ってみました。 Backhaulさせる前後でのグローバルアドレスの変化 ログの残り方 Backhaulさせた場合、セキュリティ機能はどうなるか 構成例 構成は下図の通りです。 支店のユーザから、アドレス確認サイト(www.cman.jp)へのトラフィックのみをBackhaulさせ、検証環境のSocketから検証環境のインターネット回線経由でアクセスさせるというシナリオです。 まず、Backhaulingの設定を入れる前の状態で、アドレス確認サイト(www.cman.jp)へアクセスをしてみます。 この状態で自身のアドレスの確認を行うと、この通り150.195.219.0/24のアドレスが払い出されていることがわかりました。 このアドレスはCatoクラウドの東京PoPのアドレスとなっており、CatoクラウドのPoPから宛先のアドレス確認サイト(www.cman.jp)に接続していることがわかります。 ちなみに、CatoクラウドのPoPのアドレスはこちらから確認可能です。 Production PoP Guide – Cato Learning Center (catonetworks.com) 設定手順 次に、Backhaulingの設定を行っていきます。 Backhaulingは下記の順番で設定をします。 Step１： Gatewayサイトの定義 →出口として設定したい拠点をGatewayサイトと定義します。 → 今回は、”検証環境”というサイトをGatewayサイトとして定義します。 Step２：Network Ruleの作成 →対象トラフィックをGatewayサイトに向けるためのルーティングの設定を行います。 → 今回は、支店のユーザからアドレス確認サイト(www.cman.jp)へのトラフィックのみを”検証環境”にルーティングさせます。 Gatewayサイトの定義 設定箇所：Network＞Site＞Site Configuration＞Backhauling 「Use this site as a backhauling gateway」のチェックボックスにチェックを入れます。 「Select the destination for the traffic」の設定項目が出力されます。 ここで 「Internet breakout」か「Local gateway IP」のどちらかを選択しますが、今回は「Internet breakout」を選択します。 上の手順で「Internet breakout」を選択すると「Preferred Socket Port」の設定項目が出力されます。 ここではSocketのどのポートから出力させるかを指定することができます。 今回はWAN1ポートから出力させたいので、「WAN1」を選択しました。 SocketのWANポートを冗長している場合は、「Automatic」を選択することで、自動で出力ポートを選択させることも可能です。 ここまででStep1のGatewayサイトの定義は完了です。 次にStep2のNetwork Ruleの作成に進みます。 Network Ruleの作成 中国のユーザからの接続の場合や、中国の拠点をGatewayサイトとする場合は、中国のインターネット規制に違反していないことを事前に確認し、設定を行う必要があります。 設定箇所：Network＞Network Rules 「New」からルールを作成していきます。 本記事ではNetwork Rulesの詳細な説明は省略いたしますが、今回は以下の通り設定をしています。   ・Name：Backhauling test ・Rule Type：Internet ・Source：Site(支店) ・App/Category：Domain( www.cman.jp ) ・Configuration    – Bandwidth priority：P255    – Priority Transport：CATO(Automatic)    – Secondary Transport：None ConfigurationのRouting Methodでは「Backhaul via」を選択します。 「Backhauling Gateway Site」の設定項目が出力されるので、+ボタンからStep1で設定したGatewayサイトを選択します。 最後に「Save」ボタンで設定保存をします。 以上で設定は完了です。 結果 それでは、確認項目を１つずつ確認していきます。 Backhaulさせる前後でのグローバルアドレスの変化  まず確認項目1つ目のグローバルアドレスを確認してみます。 Backhaulingの設定を入れる前の状態では、Catoクラウドの東京PoPのアドレスでした。  Backhaulingの設定が完了した後に接続をしてみると… グローバルアドレスは以下の通りISPから付与されたアドレスへと変更され、CatoクラウドのPoPからではなく検証環境のインターネット回線経由で接続されていることがわかります。 ログの残り方 この時のログを確認してみると残念ながら最終的にどのグローバルアドレスでアクセスされているかまでは確認ができませんでした。 ですが、このログから設定手順のStep2で設定したNetwork Ruleにヒットして”検証環境”というサイトから接続していることがわかります。 また、「Sub-type」と「Rule」からCatoクラウドのInternet Firewall（ルール名：Any Allow）を突破していることもわかります。 Backhaulさせた場合、Catoクラウドのセキュリティ機能はどうなるか 2つ目の確認から、Internet Firewallが機能していることが確認できましたが、念のためInternet Firewallで アドレス確認サイト(www.cman.jp)へのトラフィックをBlockするルールを作成してみました。 この状態で同じようにアドレス確認サイト(www.cman.jp)へアクセスをしてみると、下図の通りBlockされました。 よって、Backhaulされた通信もCatoクラウドを経由するため、Catoクラウドのセキュリティ機能が機能するということがわかります。 さいごに 今回はBackhaulingについて解説しました。 このBackhaulingですが、実はトラブルシューティングで利用されるケースもございます。 詳細はこちらの記事をご参照ください。 Cato経由でのWebサイト接続のトラブル例とその対処法 Cato経由でのWebサイトの接続トラブルについて、事例とその対処法についてご紹介します。 blog.usize-tech.com 2024.04.19

皆さん、こんにちは！SCSK株式会社の川原です。 今年も、Google Cloudが主催するグローバルカンファレンスイベント「 Google Cloud Next Tokyo ’24 」が開催されます！このイベントは、クラウドテクノロジーの最新情報を学び、業界リーダーや専門家とのネットワーキングを行うための絶好の機会です。 ### Google Cloud Next Tokyo ’24 概要 開催日:  2024年8月1日（木）〜2日（金） 会場 : パシフィコ横浜ノース この度当社は、Platinumスポンサーとして出展いたします！ ブレイクアウトセッション &Ask the Speaker に登壇し、 Expo 会場へのブースを出展予定 です。 IT 業界のみならず様々な業界のリーダー、意思決定者、エンジニア、そして開発者の皆様にご満足頂けるセッションコンテンツが準備されていますので、この機会をぜひ​ご活用ください。皆様のご参加を心よりお待ちしております 。 ご登録がお済でない方は、まずはこちらからご登録ください↓↓ 【招待コード  : FY24nx_pt030】 申し込み時にご入力ください ！！   イベントの見どころ Google Cloud Next Tokyo ’24では、生成AIやセキュリティをはじめ、ビジネスに欠かせないテーマを元に、基調講演、ライブセッションやハンズオンなどのプログラムが用意されています。 ☁︎  基調講演 話題の生成  AI  を筆頭に多様なプロダクト アップデートや最新のソリューションを紹介します。 また、 Google Cloud  を導入しビジネスに革新をもたらす企業のリーダーから、そのビジョンと取り組みについてお聞きします。 ☁︎  ブレイクアウト セッション & Ask the Speaker 9 つのテーマで、米  Next  で発表された最新情報やお客様によるクラウド活用事例をお届けします。 具体的な活用事例やスピーカーへの質問コーナーを活用することで、自社に役立つヒントを見つけましょう。 ☁︎  ハンズオン セッション Google Cloud  の魅力を、実際のハンズオンを通して探求しましょう。 AI 、データ分析、インフラ構築、アプリ開発、セキュリティまで、 全てを学べるチャンスです！皆さまの参加をお待ちしております。 ☁︎ Expo Google Cloud  の最新製品やソリューション、パートナー、お客様の事例やデモを、エキスパートと交流しながら体験できるエリアです。 ☁︎ Innovators Hive デベロッパーやエンジニアのためのエリアです。 Google Cloud  のデモを体験し、学習プログラムや認定資格の最新情報を入手できます。 ぜひ会場で  Google Cloud  を共に学び、デベロッパー コミュニティと繋がりましょう。   ☁︎  体験  TAP for Gen AI 生成  AI  を活用した革新的なアイデアの創出を狙った  90  分間のアイディエーションを実施します。ソリューションや手段からではなく、 課題に焦点を当てて、生成  AI  で解決すべき問題を見つけましょう。   SCSKのセッションとブースのご紹介 SCSK セッションのご紹介 開始日時：8/1（木）14:00～14:30 タイトル： 明日からできる！業務で使える！多彩なAIを組み合わせたアーキテクチャとは？ 【概要】 生成AIは、様々な業界で革新をもたらしています。そして、AIにとってデータは燃料であり、その活用がAIの性能を大きく左右します。SCSKはGoogle Cloudを通じてデータ・生成AI活用に取り組み、経験とノウハウを蓄積してきました。本セッションでは、データから従来AI・生成AIを組み合わせたアーキテクチャをご紹介し、失敗談や成功談についてお話させていただきます。   取り上げる主な Google Cloud 製品 / サービス  BigQuery Dialogflow Vertex AI Search ※セッション レベル：初級 【SCSK登壇者のご紹介】 SCSK株式会社　ソリューション事業グループ クラウドサービス事業本部 データ＆AIソリューション部 第二課 AIリードエンジニア                青 木 琢人 SCSK のクラウド専門部隊に所属する、AI / ML サービスのリードエンジニア。Google Cloud の画像認識系AI、コンタクトセンターAI、生成AIを活用し、 製造業・金融業・食品業界など幅広いお客様のシステム設計・構築を担当。 生成AIを業務活用したい方、ぜひセッションへお越しください！ SCSKブース SCSKのブースでは、 ソーシャルインパクト パートナー オブ ザ イヤーを受賞したSCSKが提供する「 総合SIer × AI ・ 生成AI の可能性 」 をテーマに、SCSKが提供するAI技術とそのビジネス活用についてご紹介いたします。SCSKは、 AIだけではなく良いシステムイングレーションやデータ整備など、業務課題の解決に必要な全体検討と組み合わせで、最適な業務実装まで支援することができる点が強みです 。当日の展示では、技術知見に留まらない、実績に基づいた具体的なシステムイメージをお伝えします。 ぜひご来場いただき、最新のAI技術とSCSKだからできるビジネスへの活用方法についてご確認ください！ では皆様、 GoogleCloudNextTokyo’24を楽しみにお待ちください。 当日はSCSKセッションならびに Ask the Speaker、 展示ブースへの来場をお待ちしております！ 【招待コード  : FY24nx_pt030】 申し込み時にご入力ください ！

坂木です。 2024年6月12日-6月14日にかけて、幕張メッセで Interop24 Tokyo が開催されました。 SCSKはZabbix Japanと共同で出展いたしましたので、出展内容や出展感想等をご紹介いたします。   イベント概要 Interop Tokyoは、日本最大級のインターネットテクノロジーイベントであり、最新の技術や最新製品を紹介しています。 イベント内容としては、各企業ブースにてパネルディスカッションやワークショップ、ショートセミナーなどが実施されています。 Zabbixブースでは、Zabbix関連ソリューションのパネルディスカッションやショートセミナーを実施しました。   SCSKのZabbixブース出展内容 SCSKの展示では 監視ツールの移行 と Zabbix自動チューニング を紹介しました。 監視ツールの移行 Zabbixは、オープンソースソフトウェア（OSS）のためライセンス料がかからず、有償監視ツールから移行するとコストメリットが大きいことをご紹介しました。 また、監視ツール移行の手間という観点から見ても、Zabbixへの移行は自動化できる部分が多く、オペレーターの負担が少ないことも併せてご説明しました。 Zabbix自動チューニング 生成系AIを活用して、エラー内容の分析・原因調査・解決策提示を自動化する取り組みを紹介しました。 また、AIからの回答を元に、設定ファイルのエラー原因となっている箇所を自動で修正する手法も提案し、エラー発生から解決まで一切人を介在させず実現できることを示しました。   ちなみに、私は上記2項目を題材としてショートセミナーにて講演いたしました。 AI分野に興味を持つ方が多いのか、Zabbix自動チューニングの話をしているときは特に食いつきがよかった気がします。   感想 まず第一に、人が多いです。 Interopは規模が大きいITイベントということもあり、出店企業や参加者が非常に多かったです。   Interopでは各企業が最新のサービス・製品紹介を行っています。私はいくつかの企業ブースで話を伺いましたが、どれも聞いてて飽きることのない魅力的な内容で、多くの知見を得ることができました。 また、各企業ブースに話を聞きに行くとノベリティがもらえます。知見とノベリティが得られて一石二鳥です。 ちなみに、私は今治タオルとハイチュウをもらいました。   最後に 私は入社2年目で、IT業界での経験は浅く高い専門性を有してはいませんが、インタロップは楽しめました。そのため、ITに精通しているとまで言わなくても、多少ITを知っている方であれば楽しめるイベントだと思います。

こんにちは、広野です。 Amazon API Gateway REST API のロギングにはいくつか種類と方法がありますが、Amazon CloudWatch Logs は他の AWS サービスのログを見るときにも日々アクセスするため、なんだかんだ言うものの慣れているというのと、設定が簡単なので使いやすいです。 ですが、Amazon API Gateway に Amazon CloudWatch Logs に書き込みを許可する IAM ロールはその AWS アカウント共通の設定 なので、そのアカウントで最初に設定すると以後気にしなくなりますし、そもそも最初から設定されていたアカウントで作業する場合は何もすることがありません。そのため、私は新しい AWS アカウントで作業するときに必ずこの設定を忘れます。思い出すタイミングは、Amazon API Gateway のログ設定を有効にしようとしてエラーになるときです。 以下、備忘のため設定方法を書き落としておきます。 設定方法 まずは公式ドキュメントから。 API Gateway での CloudWatch による REST API のログの設定 - Amazon API Gateway Amazon API Gateway で CloudWatch によるログを設定する方法について説明します。 docs.aws.amazon.com   IAM ロールを作った後は、AWS マネジメントコンソールの以下の画面で IAM ロールを登録するだけです。   一応、AWS CloudFormation テンプレートにも落とし込んでおいたので、これを一発流すだけでも一通り設定できます。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates an IAM Role and an account setting to push CloudWatch Logs from API Gateway. This setting is shared in your AWS account. Resources: # ------------------------------------------------------------# # API Gateway CloudWatchLogs Invocation Role (IAM) # ------------------------------------------------------------# ApigCloudWatchLogsInvocationRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ApigCloudWatchLogsInvocationRole-${AWS::AccountId} Description: This role allows all API Gateways to invoke CloudWatch Logs. AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - apigateway.amazonaws.com Action: - sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AmazonAPIGatewayPushToCloudWatchLogs ApigAccountSettingCloudWatchLogs: Type: AWS::ApiGateway::Account Properties: CloudWatchRoleArn: !GetAtt ApigCloudWatchLogsInvocationRole.Arn DependsOn: - ApigCloudWatchLogsInvocationRole   まとめ いかがでしたでしょうか？ このように AWS にはアカウント単位の共通設定がたまにあるので、管理方法も含めて気を付けていきましょう。 本記事が皆様のお役に立てれば幸いです。

こんにちは、SCSK株式会社の小寺崇仁です。 今回は「データベースモニタ」について設定方法を紹介します。 データベースモニタとは Zabbixのアイテムタイプに「データベースモニタ」があります。 データベースモニタでは、ZabbixサーバにインストールしたODBCドライバを使用して、監視対象のデータベースに接続し、任意のSQLを発行することができます。 このブログでは、ODBCドライバのインストール方法、アイテムの作成方法をご紹介します。 検証環境 AWS EC2 OS Red Hat Enterprise Linux release 9.4 (Plow) Zabbix 7.0.0 MySQL/MariaDB 10.5.22-MariaDB PostgreSQL PostgreSQL 13.14 on x86_64-redhat-linux-gnu SQLサーバ（MSSQL） Microsoft SQL Server 2019 (RTM-CU26) (KB5035123) – 15.0.4365.2 (X64) Oracle Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 – Production MySQL/MariaDB ODBCドライバのインストール（MySQL/MariaDB） # dnf install mariadb-connector-odbc インストールされたドライバのパスを確認（MySQL/MariaDB） cat /etc/odbcinst.ini ～～～～～～～～～～ [MariaDB] Description=ODBC for MariaDB Driver=/usr/lib/libmaodbc.so Driver64=/usr/lib64/libmaodbc.so FileUsage=1 ～～～～～～～～～～ アイテム作成（MySQL/MariaDB） アイテム名 任意   タイプ データベースモニタ   キー ※1行です。 db.odbc.select[ mysql_example, , Driver=/usr/lib64/libmaodbc.so; Database=zabbix; Server=127.0.0.1; Port=3306] Select用のキー 任意文字(第1引数) 不使用(第2引数) 上記で確認したパス 接続先のDB名 接続先のサーバ 接続先のポート データ型 任意   ユーザ DB接続ユーザー   パスワード DB接続パスワード   SQLクエリ 実行SQL 例：select version();   PostgreSQL ODBCドライバのインストール（PostgreSQL） # dnf install postgresql-odbc インストールされたドライバのパスを確認（PostgreSQL） cat /etc/odbcinst.ini ～～～～～～～～～～ [PostgreSQL] Description=ODBC for PostgreSQL Driver=/usr/lib/psqlodbcw.so Setup=/usr/lib/libodbcpsqlS.so Driver64=/usr/lib64/psqlodbcw.so Setup64=/usr/lib64/libodbcpsqlS.so FileUsage=1 ～～～～～～～～～～ アイテム作成（PostgreSQL） アイテム名 任意   タイプ データベースモニタ   キー ※1行です。 db.odbc.select[ pgsql_example, , Driver=/usr/lib64/psqlodbcw.so; Database=zabbix; Server=127.0.0.1; Port=5432] Select用のキー 任意文字(第1引数) 不使用(第2引数) 上記で確認したパス 接続先のDB名 接続先のサーバ 接続先のポート データ型 任意   ユーザ DB接続ユーザー   パスワード DB接続パスワード   SQLクエリ 実行SQL 例：select version();   SQLServer（MSSQL） ODBCドライバのインストール（MSSQL） # curl https://packages.microsoft.com/config/rhel/9/prod.repo | sudo tee /etc/yum.repos.d/mssql-release.repo # dnf install -y msodbcsql18 参考： https://learn.microsoft.com/ja-jp/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-for-sql-server?view=sql-server-ver16&tabs=redhat18-install%2Calpine17-install%2Cdebian8-install%2Credhat7-13-install%2Crhel7-offline インストールされたドライバのパスを確認（MSSQL） cat /etc/odbcinst.ini ～～～～～～～～～～ [ODBC Driver 18 for SQL Server] Description=Microsoft ODBC Driver 18 for SQL Server Driver=/opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.3.so.3.1 UsageCount=1 ～～～～～～～～～～ アイテム作成（MSSQL） アイテム名 任意   タイプ データベースモニタ   キー ※1行です。 db.odbc.select[ mssql_example, , Driver=/opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.3.so.3.1; Database=master; Server=10.0.0.1; Port=1433; TrustServerCertificate=yes;] Select用のキー 任意文字(第1引数) 不使用(第2引数) 上記で確認したパス 接続先のDB名 接続先のサーバ 接続先のポート 接続エラー対策 データ型 任意   ユーザ DB接続ユーザー   パスワード DB接続パスワード   SQLクエリ 実行SQL 例：SELECT @@VERSION AS ‘SQL Server Version’;   Oracle ODBCドライバのインストール（Oracle） # mkdir /opt/oracle # cd /opt/oracle # wget https://download.oracle.com/otn_software/linux/instantclient/2111000/instantclient-basic-linux.x64-21.11.0.0.0dbru.zip # wget https://download.oracle.com/otn_software/linux/instantclient/2111000/instantclient-odbc-linux.x64-21.11.0.0.0dbru.zip # unzip instantclient-basic-linux.x64-21.11.0.0.0dbru.zip # unzip instantclient-odbc-linux.x64-21.11.0.0.0dbru.zip # echo /opt/oracle/instantclient_21_11 > /etc/ld.so.conf.d/oracle-instantclient.conf # ldconfig 参考： https://www.oracle.com/jp/database/technologies/instant-client/linux-x86-64-downloads.html アイテム作成（Oracle） アイテム名 任意   タイプ データベースモニタ   キー ※1行です。 db.odbc.select[ oracle_example, , Driver=/opt/oracle/instantclient_21_11/libsqora.so.21.1; Server_Name=10.0.0.2/ORCL; Port=1521] Select用のキー 任意文字(第1引数) 不使用(第2引数) 上記で確認しパス 接続先のサーバ/SID 接続先のポート データ型 任意   ユーザ DB接続ユーザー   パスワード DB接続パスワード   SQLクエリ 実行SQL 例：select * from v$version;   動作状況 このような形でデータ取得ができます。 最後に 弊社では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アカウントを開設しました！★ 【公式】SCSK Zabbix (@SCSK_Zabbix) / Twitter SCSKが提供するZabbixサービスのオフィシャルアカウントです。 #Zabbix #SCSKPlusサポートforZabbix #監視 #SCSK twitter.com

こんにちは、SCSK株式会社の小寺崇仁です。 今回は「Java(JMX)監視」について設定方法を紹介します。 Java(JMX)監視とは Javaのプロセス内部は複雑で、独自のメモリ管理や、様々な処理が行われています。ZabbixではJavaのプロセスを監視することができ、テンプレートも準備されています。 しかし、設定が難しくあまり使われていないように思います。今回は、Zabbixサーバ側の設定とプロセス側の設定についてご紹介します。 Zabbixサーバーの設定 Javaを監視するには、「zabbix-java-gateway」といパッケージをインストールする必要があります。 「zabbix-java-gateway」サービスを起動して、「zabbix-server」から接続する設定をします。 インストール # dnf install zabbix-java-gateway # systemctl start zabbix-java-gateway # systemctl enable zabbix-java-gateway 設定 # vi /etc/zabbix/zabbix_server.conf JavaGateway=127.0.0.1 StartJavaPollers=1 # systemctl restart zabbix-server Javaプロセス側の設定 Javaのプロセス側ではJMXでリモート接続できるようにする必要があります。 設定を有効にするには起動時に以下のオプションを設定します。 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false 次に設定方法の例をご紹介します。 単純なJavaプロセス 起動時の引数に設定します。先日の Seleniumサーバ の場合、次のように設定します。 java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -jar selenium-server-4.21.0.jar standalone --selenium-manager true Tomcatの場合  次の手順で確認しました。Tomcatではsetenv.shを作成すればオプションを読み込みます。 # mkdir /opt/tomcat # cd /opt/tomcat/ # wget https://dlcdn.apache.org/tomcat/tomcat-10/v10.1.25/bin/apache-tomcat-10.1.25.tar.gz # tar zxvf apache-tomcat-10.1.25.tar.gz # vi /opt/tomcat/apache-tomcat-10.1.25/bin/setenv.sh #!/bin/sh CATALINA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false" export CATALINA_OPTS # /opt/tomcat/apache-tomcat-10.1.25/bin/startup.sh Zabbixのホスト作成 ホスト 任意   テンプレート Generic Java JMX Apache Tomcat by JMX 単純なプロセス用 Tomcat用 ホストグループ 任意   インターフェース JMX   　IPアドレス プロセスが起動しているサーバのIP   　ポート 引数で指定したポート   値の取得 このような形で値の取得ができます。 最後に 弊社では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アカウントを開設しました！★ 【公式】SCSK Zabbix (@SCSK_Zabbix) / Twitter SCSKが提供するZabbixサービスのオフィシャルアカウントです。 #Zabbix #SCSKPlusサポートforZabbix #監視 #SCSK twitter.com

こんにちは、SCSK株式会社の小寺崇仁です。 先日Zabbixの7.0がリリースされました。 今回は「ブラウザモニタリング」について検証していきます。 ブラウザモニタリングとは ブラウザモニタリングとは、アイテムのタイプ「ブラウザ」というZabbix7.0の新機能になります。ブラウザを使用したWebサイトの操作をZabbixで再現して監視を行う機能になります。 Webシナリオ監視と類似した機能になりますが、違いは以下となります。 監視タイプ 概要 設定難易度 ブラウザモニタリング Seleniumを使用したスクレイピング 優しい Webシナリオ HTTPリクエスト、レスポンスを自作したスクレイピング 激ムズ 環境準備 ブラウザモニタリングを使用するには、Zabbix7.0とは別に、「WebDriverサーバ」を構築する必要があります。 「WebDriverサーバ」を構築する方法としては以下の2パターンあります。 SeleniumのDockerイメージを使用する SeleniumのStandaloneサーバを起動する ZabbixサーバにDockerを入れたくなかったので、私は２で検証をしました。 Dockerを使用する 検証はしておりませんが、次のURLに構築手順が記載してあります。 https://assets.zabbix.com/files/events/2024/conference_benelux_2024/KasparsM_browser_monitoring.pdf Standaloneを使用する 次の流れで、Selenium Standalone サーバを構築します。 Javaをインストールします。 Seleniumの公式HPから「Selenium Server (Grid)」をダウンロードします。 Selenium Standalone サーバを起動します。 Zabbixサーバのconfを編集します。 私が構築した際のコマンドは以下となります。 1.Java インストール # dnf install java-21-openjdk 2.Seleniumダウンロード # wget https://github.com/SeleniumHQ/selenium/releases/download/selenium-4.21.0/selenium-server-4.21.0.jar 3.Selenium起動 ※「--selenium-manager true」をオプションを付けることで各ブラウザのドライバーを自動ダウンロードできます。 # java -jar selenium-server-4.21.0.jar standalone --selenium-manager true 4.Zabbixサーバのconf編集 # vi /etc/zabbix/zabbix_server.conf WebDriverURL=http://localhost:4444 StartBrowserPollers=1 ※以下のバージョンで検証した際にエラーとなりました。そのため、Firefoxのドライバーを使用して回避しました。 Selenium-server：4.21.0、ChromeDriver：126.0.6478.126 アイテムの作成 サンプルでZabbixの管理画面にログインをして、キューの画面を監視したいと思います。 標準テンプレートで全体のキューの数しかわからないので、個別で監視を入れたいと思います。 項目 設定値 備考 アイテム名 キュー監視   タイプ ブラウザ   キー 任意   データ型 テキスト   スクリプト 次に記載   var browser = new Browser(Browser.firefoxOptions()); browser.navigate("http://localhost/zabbix/"); browser.findElement('css selector','#name').sendKeys("Admin"); browser.findElement('css selector','#password').sendKeys("zabbix"); browser.findElement('css selector','#enter').click(); browser.navigate("http://localhost/zabbix/zabbix.php?action=queue.overview"); return　browser.findElement('xpath','/html/body/div/main').getText(); ※Chromドライバーを使用するとエラーになったため、Firefoxを使用しています。 ※最後に「getText」で文字列を取得していますが、「getScreenshot」で画像（バイナリデータ）の保存もできます。画像データの表示については別途検証する予定です。 ※スクリプトを作成する際に以下のマニュアルが参考になります。 https://www.zabbix.com/documentation/current/en/manual/config/items/itemtypes/browser https://www.zabbix.com/documentation/current/en/manual/config/items/preprocessing/javascript/browser_item_javascript_objects 監視データ（取得値） このような形でキューの画面の内容をテキスト保存できます。 総括 ブラウザモニタリングでSeleniumが使用できるようになり、監視設定がとても簡単になったと思います。 （Webシナリオ監視では、リクエストを自作する必要があったため、hiddenにトークンが仕込まれていたり、jQueryでお洒落なつくりをしていた場合、発狂していました。） 今後はブラウザモニタリングが主流になっていくと思いますので、ぜひご活用ください。 最後に 弊社では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アカウントを開設しました！★ 【公式】SCSK Zabbix (@SCSK_Zabbix) / Twitter SCSKが提供するZabbixサービスのオフィシャルアカウントです。 #Zabbix #SCSKPlusサポートforZabbix #監視 #SCSK twitter.com

こんにちは！SCSK の中山です。   先日、Cato×SCSKで開催された「Catoクラウド 1Dayハンズオンセミナー@東京」に参加してきました！ 私は4月に異動でCatoを担当することになり、今回は勉強のために参加させていただきましたが、”Catoとは何か”を理解するにはとても良いハンズオンでした。 少しセミナーから時間が経ってしまいましたが、今回はその内容をあくまで感想ベースで記事にしてみたいと思います。 この記事を見てCatoやセミナーの内容が気になった方は、大阪、名古屋で開催されるセミナーにページ下部のリンクよりお申し込みが可能です。   ハンズオン概要 Cato×SCSKで開催しているハンズオンセミナーは、私が参加した東京を含めた5都市で行われています。 このセミナーでは、Catoの導入にあたって使用するソケットを実際に触りながら、各機能をハンズオン形式で試すことができます。 参加人数も少ないため、ハンズオンで困った点や気になった点があれば、直接対応していただけます。 また、講師はCato社のエンジニアの方なので、その場でQ&Aに応じていただけるほか、Catoの導入を検討しているユーザー様であれば、弊社営業を含めた相談もできる体制になっています。   ●会場の様子 少人数のため、ハンズオンで詰まった時のフォローが手厚かったです。   当日のアジェンダ セクション   内容 時間 1 オープニング ・ご挨拶 ・ Cato×SCSK の取り組み紹介 ・ Cato Networks 紹介 /Cato クラウド概要 10:00–10:45 ２ ハンズオン（ AM ） ・ Cato 管理ポータル（ Cato Management Application ）概要 ・ Cato Socket ・ SD-WAN 10:45–12: １ 5 ３ 休憩 各自お昼休憩（ 60 分） 12: １ 5–13:15 ４ ハンズオン（ PM ） ・ ZTNA ・ Internet Firewall/WAN Firewall ・ TLS インスペクション / アンチマルウェア /IPS ・ RBI/CASB/DLP 、等 13:15–15:45 5 クロージング ・ Q ＆ A ・ご検討にあたって ・ Tips 、等 15:45–16:30   以降は当日の各アジェンダの概要を記載していきます。 オープニング Cato Networks社のチャネルセールスエンジニアの大森様より、Cato社、Catoクラウドの概要の説明をいただきました。 個人的に聞いていて以下の点が面白いなーと思いました。 Catoクラウドは”SASE”という言葉が生まれる前からサービス稼働している。 Catoクラウドをご存じの方はCatoクラウド=1SASE製品という認識されている方が多いのかなと思ってます。 実は”SASE”という言葉が生まれる前から、Catoクラウドは”SASE”の概念を持って設計されたサービスになっており、”SASE”という概念・言葉が生まれることにも携わっているというのが驚きでした！ Catoはシングルエンジンで稼働している。 Catoクラウドには様々なサービスがありますが、基本的なサービスはすべてPoP上で処理をしており、同じ構成を使って処理をしているとのことです。 これによりユーザとしてはログが同じ形式で出てくるため、まとめて確認・検索ができるようになります。 当たり前のようにコンソールから確認してましたが、セキュリティとネットワークのログをまとめて見れるって従来のセキュリティ・ネットワーク製品では意外とできなかったなと思いました。 ハンズオン環境 今回ハンズオンで使用する環境は以下の通りです。 会場にはユーザ2名ごとにソケットが用意されており、2名ごとにこちらの環境を参加者ごとに作成しました。   ハンズオン(AM) 午前中はソケットをインターネットに接続し、Cato管理ポータル（以下、CMA）から作成したサイト（各拠点）とソケットを紐づけ、ソケットからCatoを経由して通信することを確認しました。 その後、固定IPを指定することで、固定IPからNetflixのサイトにアクセスし、日本向けではなくドイツ向けのページにアクセスできることを確認しました。 ◆サイトの作成 会場からSite接続するために、ハンズオンの会場を1つの拠点と見立ててサイトを作成。   ◆PoP指定(frankfurt) Netflixへの接続時に、フランクフルト(ドイツ)のPoPが出口となるように、Network Ruleを追加。   ◆接続確認 フランクフルトからのアクセスとみなされ、ドイツのNetflixサイトが表示されることを確認。   ハンズオン(PM) 午後は、午前に行ったソケット経由のアクセスに続いて、各PCからのクライアント接続から始まり、アジェンダに記載された各種機能（CASB、RBIなど）の説明とハンズオンを実施しました。 以下にハンズオンで実際に試した内容を紹介します。   ◆ZTNA(Zero-Trust Network Access) 今回は、コンソールからモバイルアクセス用のユーザーを新規で作成し、アクセスを行いました。 午前の内容ではサイト接続からのルールを追加していたため、モバイル接続からのアクセスではルールが適用されず、日本のNetflixのページが表示されました。   ◆CASB(Cloud Access Security Broker) CASBとはCloud Access Security Brokerの略でSaaSサービスへの処理を制限することができる機能になります。 実際に使用する場面としては、ファイルの受け渡しでクラウドストレージからファイルのダウンロードはしたいけれど、ファイルのアップロードはさせたくないという場合に使える機能です。 ハンズオンでは、YouTubeの動画再生のみを制限し、YouTubeにアクセスはできるけれど動画を見ることはできないという形でCASBを実際に試しました。 ・Application Controlより、YouTubeの「watch stream」をブロックするルールを追加。 ・YouTubeの動画が見れないことを確認。 ◆RBI(Remote Browser Isolation) RBIとは、手元のクライアントのブラウザから直接Webページにアクセスするのではなく、クラウドの仮想環境上のブラウザからWebページにアクセスし、その映像をクライアントのブラウザに表示する機能です。 これにより、クライアントから直接Webページにアクセスすることがないので、Webページに含まれる脅威からクライアントを守ることができます。 Catoでは、危険なページへのアクセスはそもそもブロックすべきとのことで、グレーなサイトへのアクセス時に使用することが推奨されています。 今回のハンズオンでは、グレーゾーンのサイトへのアクセスではなく、RBIのテスト用のページにアクセスしました。   ・RBIが有効化されていることの確認。 ・Internet FirewallにCategoryが「Uncategorized」「Undefined」のページに対して、Actionが「RBI」でアクセスするようなルールを追加する。 ・「rbicheck.com」というRBIのテストサイトにアクセスし、ファイルのダウンロードが防がれていることを確認する。 最後に 私が参加したハンズオンセミナーの内容の一部を記事にしてみました。 今回のハンズオンや説明を受けた内容は、Cato導入時に必要な作業や知識であり、私のようにCatoを扱い始めた人や、今Catoの導入を検討しているけれど何ができるか、何をすればいいのか分からないという人にピッタリの内容だと思います。 東京開催は終わってしまいましたが、まだ4か所で開催予定ですので、 Catoクラウドを触ってみたい！ Catoって何ができるのか、イマイチ分からん、、 という方々は、場所や時間の都合もあるかと思いますが、ぜひ参加してみてください！   ●大阪(日程：7/18(木)) 世界初のSASEプラットフォーム Catoクラウド ハンズオンセミナー《午後開催》～全国5都市開催（東京/大阪/名古屋/博多/札幌）～ クラウドサービスの利用が拡大しワークスタイルが大きく変化する中、ランサムウェアを始めとするサイバー攻撃はより複雑・巧妙化し、被害は拡大の一途をたどっています。そこで、従来のネットワーク/セキュリティのレガシーアーキテクチャが抱える様々な課題... www.scsk.jp   ●名古屋(日程：7/25(木)) 世界初のSASEプラットフォーム Catoクラウド ハンズオンセミナー《午後開催》～全国5都市開催（東京/大阪/名古屋/博多/札幌）～ クラウドサービスの利用が拡大しワークスタイルが大きく変化する中、ランサムウェアを始めとするサイバー攻撃はより複雑・巧妙化し、被害は拡大の一途をたどっています。そこで、従来のネットワーク/セキュリティのレガシーアーキテクチャが抱える様々な課題... www.scsk.jp

みなさんこんにちは、鎌田です。 Prisma Cloud を使ったサービス開発、運営を行っている中での気づきや、使いこなし方などを皆さんと共有することで、クラウドセキュリティの重要性の認知度や対策レベルをみんなで徐々に上げられればいい、そういうモチベーションのブログ記事です。 ただの情報発信ではなく、Prisma Cloud の使いこなし方や、失敗から学んだ教訓など、少し具体的な実務よりの内容も共有していければと思います。 少し前に、Prisma Cloud の主の機能の１つ、CWPPについて確認、検証を行いましたので、これからそのナレッジを発信していきたいと思います。 今回は初回ということで、CWPPのアーキテクチャについて解説したいと思います。 CWPPのアーキテクチャ Prisma Cloud のCWPP機能は、大きく以下のアーキテクチャで成り立っています。 Prisma Cloud Console : セキュリティとコンプライアンスの管理を一元化するためのユーザーインターフェース Intelligence Stream（IS） : 最新の脅威インテリジェンスを提供するための機能 Defender : 各クラウドワークロード（仮想マシン、コンテナ、Kubernetesなど）に対するエージェント Radar : セキュリティ脅威やリスクをリアルタイムで可視化する機能 WildFire : 悪意のあるファイルや未知の脅威を分析し、インテリジェンスを提供するサービス これらの構成要素の関連を図にすると以下のようになります。 Prisma Cloud コンソールは、ISから脅威情報、Defenderからスキャン結果や不正な処理情報を受け取り、突き合わせを行い、危険な状態を可視化、アラート通知するというのが大まかな仕組みです。 そしてこれらのアーキテクチャをもとに、脆弱性・コンプライアンスの管理や、ランタイムプロテクション、ネットワークセグメンテーションといった機能を提供しています。 機能の説明は次回行いますので、今回はアーキテクチャについてもう少し具体的に解説していきます。 Intelligence Stream Prisma Cloud Intelligence Stream (IS) は、既知の脆弱性データベース、公式ベンダーフィード、各プロバイダーから集めた脆弱性データや脅威インテリジェンスをほぼリアルタイムに提供します。Prisma Cloud コンソールは自動的にISに接続し、特別な設定なしでアップデートをダウンロードします。IS は1日に数回更新され、コンソールは常にアップデートをチェックしてくれるので安心です。 Defender Defenderは、クラウド環境におけるワークロードやリソースをリアルタイムで保護するエージェントです。コンテナ、ホスト、サーバーレス環境など、さまざまなクラウドリソースを防御するために設計されています。仕様や動作原理については別の記事で詳しく解説予定ですので、ここでは、クラウド環境のワークロードを防御するためのエージェントという感じで理解しておいてもらえれば大丈夫です。 Radar 一言でいうと、クラウド環境におけるリソースの配置、接続状況、セキュリティリスクを視覚的に表示するダッシュボードのような機能を、よりグラフィカルな形で提供してくれるものです。以下のような情報をまとめてくれます。 クラウドリソースの全体マップ 各リソースのセキュリティステータス ネットワークトラフィックの視覚化 リソース間の依存関係と接続状況 WildFire Palo Alto Networksが提供するマルウェア分析および脅威インテリジェンスサービスで、以下のような解析を行います。 静的解析 ：ファイルのコードを解析し、悪意のあるパターンを検出します。 動的解析 ：サンドボックス環境でファイルを実行し、その動作を観察します。これにより、未知のマルウェアも検出できます。 機械学習 ：機械学習アルゴリズムを使用して、未知のマルウェアを検出し、既知のマルウェアと比較して分類します。 まとめ CWPPの構成要素について解説しました。初回ということでまずは簡単な解説までとなりますが、この後は各構成要素を深掘りしたり、導入や設定等、実際に手を動かしてみたところを、より具体的に解説していこうと考えています。 最後に、当社では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

こんにちは。SCSKのふくちーぬです。 2024/6/26時点で、Amazon InspectorのLambdaコードスキャンがPython3.12のランタイムでも動作確認できたので紹介します。   Amazon Inspector とは Amazon Inspector は、ソフトウェアの脆弱性やネットワークの接続性について AWS ワークロード(Amazon EC2,Amazon ECR,AWS Lambda)を継続的にスキャンする脆弱性管理サービスです。 Lambda スキャンについて 種類 説明 Lambda 標準スキャン Lambda 関数とそのレイヤー内のアプリケーションの依存関係をスキャンして、パッケージ脆弱性がないか調べます。  Lambda コードスキャン 関数やレイヤー内のカスタムアプリケーションコードをスキャンして、コードの脆弱性がないか調べます。   Amazon Inspector による AWS Lambda 関数のスキャン - Amazon Inspector Amazon Inspector による AWS Lambda 関数のサポートにより、Lambda 関数とレイヤーのセキュリティ脆弱性を継続的に自動評価できます。Amazon Inspector では、2 種類の Lambda スキャンを提... docs.aws.amazon.com 検証 今回は、Lambdaコードスキャンに着目して脆弱性の検出及び修正を実施します。 Amazon Inspector の有効化 以下手順に従って、有効化しておいてください。 15日間の無料トライアル期間があります。料金は、スキャンした回数に応じて課金されますのでご留意ください。 Amazon Inspector の開始方法 - Amazon Inspector Amazon EC2、Amazon ECR、および Lambda リソースタイプ全体の脆弱性を検出するためのベストプラクティス設定で Amazon Inspector をセットアップします。 docs.aws.amazon.com AWS CloudFormation テンプレート 以下のテンプレートをデプロイしてください。 ここでは、脆弱性を持つコードとして機密情報をハードコーディングしています。 AWSTemplateFormatVersion: 2010-09-09 Description: For Lambda Code Scan Parameters: ResourceName: Type: String Resources: # ------------------------------------------------------------# # Lambda # ------------------------------------------------------------# Function: Type: AWS::Lambda::Function Properties: FunctionName: !Sub ${ResourceName}-lambda-function Role: !GetAtt LambdaRole.Arn Runtime: python3.12 Handler: index.lambda_handler # Environment: # Variables: # AWS_SECRET_ACCESS_KEY: '{{resolve:secretsmanager:aws_secret_access_key:SecretString:sample_key::}}' Code: ZipFile: !Sub | import boto3 import os import json def create_session_noncompliant(): import boto3 # Noncompliant: uses hardcoded secret access key. sample_key = "AjWnyxxxxx45xxxxZxxxX7ZQxxxxYxxx1xYxxxxx" boto3.session.Session(aws_secret_access_key=sample_key) #def create_session_compliant(): # import boto3 # # Compliant: uses environment variable for secret access key. # sample_key = os.environ.get("AWS_SECRET_ACCESS_KEY") # boto3.session.Session(aws_secret_access_key=sample_key) def lambda_handler(event, context): create_session_noncompliant() # create_session_compliant() return { 'statusCode': 200, 'body': json.dumps('Hello form Lambda') } # ------------------------------------------------------------# # Log Group # ------------------------------------------------------------# FunctionLogGroup: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub "/aws/lambda/${Function}" # ------------------------------------------------------------# # IAM Role # ------------------------------------------------------------# LambdaRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ${ResourceName}-lambda-role AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: sts:AssumeRole Principal: Service: - lambda.amazonaws.com ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole   脆弱性の検出 パスワードやアクセス キーなどのアクセス資格情報を、ソース コードにハードコードしたため、脆弱性が検出されました。 ディテクターの名前を押下すると、以下のリンクに飛びます。 Hardcoded credentials | Amazon CodeGuru, Detector Library Credentials, such as passwords and access keys, should not be hardcoded in source code. docs.aws.amazon.com 脆弱性が発生した箇所もピンポイントで示してくれます。 内部で生成AIが利用され自動推論と機械学習を使用してコードを評価してくれるおかげで、修復方法も一目瞭然です。 ランタイムPython3.12でも検出されることを確認できました。 提案された修正コードを利用して、Lambdaを更新していきます。 AWS Secrets Manager の作成 機密情報をテンプレート内に記載するのではなく、AWS Secrets Manager から読み取るために事前にSecretを作成しておきます。 AWS Secrets Manager シークレットを作成する - AWS Secrets Manager AWS Secrets Managerでシークレットを作成する方法について説明します。 docs.aws.amazon.com 脆弱性を持つコードの修正 以下のテンプレートを使用して、スタックを更新します。 AWSTemplateFormatVersion: 2010-09-09 Description: For Lambda Code Scan Parameters: ResourceName: Type: String Resources: # ------------------------------------------------------------# # Lambda # ------------------------------------------------------------# Function: Type: AWS::Lambda::Function Properties: FunctionName: !Sub ${ResourceName}-lambda-function Role: !GetAtt LambdaRole.Arn Runtime: python3.12 Handler: index.lambda_handler Environment: Variables: SAMPLE_SECRET_ACCESS_KEY: '{{resolve:secretsmanager:aws_secret_access_key:SecretString:sample_key::}}' Code: ZipFile: !Sub | import boto3 import os import json # def create_session_noncompliant(): # import boto3 # # Noncompliant: uses hardcoded secret access key. # sample_key = "AjWnyxxxxx45xxxxZxxxX7ZQxxxxYxxx1xYxxxxx" # boto3.session.Session(aws_secret_access_key=sample_key) #def create_session_compliant(): import boto3 # Compliant: uses environment variable for secret access key. sample_key = os.environ.get("SAMPLE_SECRET_ACCESS_KEY") boto3.session.Session(aws_secret_access_key=sample_key) def lambda_handler(event, context): # create_session_noncompliant() create_session_compliant() return { 'statusCode': 200, 'body': json.dumps('Hello form Lambda') } # ------------------------------------------------------------# # Log Group # ------------------------------------------------------------# FunctionLogGroup: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub "/aws/lambda/${Function}" # ------------------------------------------------------------# # IAM Role # ------------------------------------------------------------# LambdaRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ${ResourceName}-lambda-role AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: sts:AssumeRole Principal: Service: - lambda.amazonaws.com ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole Amazon Inspector の確認 Amazon Inspector の検出結果画面にて、該当のLambdaが表示されていません。 無事コード脆弱性に対処することができました。 まとめ ・実環境でPython3.12についてもLambdaコードスキャンの対象として動作を確認しました。 日本語ドキュメントでは、Python3.12はサポートされていないと記述されておりますが、英語ドキュメントではサポートしている旨が記述されています。 Amazon Inspector でサポートされているオペレーティングシステムとプログラミング言語 - Amazon Inspector Amazon Inspector が脆弱性を検出するためにスキャンできるオペレーティングシステムとプログラミング言語について説明します。 docs.aws.amazon.com Operating systems and programming languages that Amazon Inspector supports - Amazon Inspector Learn about the operating systems and programming languages that Amazon Inspector supports to detect vulnerabilities. docs.aws.amazon.com ※2024/2/21時点では、日本語ドキュメント及び英語ドキュメント双方ともPython3.11までしかサポートしておりませんでした。実環境においてもPython3.12を検証したところ、スタータス欄に”サポートされていないランタイム”と表示され、コードスキャンの対象外であることを確認済みでした。 他のランタイムについては、本検証では未確認となりますので、Amazon Inspector 及び AWS Lambda 導入時にはご自身で検証の上ご利用ください。 最後に いかがだったでしょうか。 公式ドキュメントを英語で読むこと、きちんと動作検証をすることが重要であることを実感する良い機会になりました。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

こんにちは、SCSK株式会社の川原です。 6月20日～21日の2日間にわたり、幕張メッセで開催された” AWS Summit Japan 2024 “に出展しました。 SCSKはプラチナスポンサーとして、スポンサーセッションとブースを出展しました！ 出展概要に関する内容は、以下をご確認ください。 AWS Summit Japan 2024に出展します！ SCSKは 2024/6/20(木)～6/21(金)開催の日本最大の AWS を学ぶイベント「AWS Summit Japan」に出展します。 SCSKセッションでは、”データセンターのラックぜんぶ抜く！SCSK だからできる脱オンプレの秘策とは？”というテーマで、沖電気工業様のマイグレーション事例をご紹介いたします。 blog.usize-tech.com 2024.05.09 当社セッション クラウド Lift & Shift の秘訣 について、沖電気工業様と当社の取り組みをご紹介させていただきました。2日目の最終セッションにもかかわらず、多くの方々にご来場いただきました。 今回は、沖電気工業株式会社のCIOである高島様にご登壇いただき、共にお話しできたことで、クラウド移行を成功させるために両社がどのように協力し、その困難を乗り越えたのかをより深くご理解いただけたのではないかと思います。 足を運んでいただいた皆様ありがとうございました！ 出展ブース 展示ブースでは、「 AWS愛が、凄い。SCSK 」をテーマに、 SCSK独自ソリューションの4商材を展示、ミニシアターでは7つのAWS関連ソリューションから発表させていただきました 。出展ブースの詳細に関しては、以下の記事をご確認ください。 【近日開催！】AWS Summit Japan 2024「AWS愛が、凄い。SCSK」ブースのご紹介！ SCSKは、いよいよ開催が迫る「AWS Summit Japan」に出展します。 ブースでは「AWS愛が、凄い。SCSK」をテーマに独自ソリューションの4商材を展示、ミニシアターで7つのAWS関連ソリューションから発表いたします。 blog.usize-tech.com 2024.06.11   展示商材 展示商材のご紹介では、 実際のデモンストレーションを通じて、各ソリューションの具体的な機能や利便性を直接体験していただくことができました 。各ソリューションがどのようにお客様のビジネス課題を解決するのか、より深く理解していただけたことと思います。   ミニシアター ミニシアターでは、7つのAWS関連ソリューションについて1日に各2回ずつ講演を行いました。 最新の技術トレンドを交えながら、SCSKの豊富なソリューションの特長やAWS活用について専門スタッフがご紹介しました 。 当日表彰された AWS Ambassador や AWS Top Engineer も多く登壇し、多くのお客様が足を止めて聞いてくださいました。   予想を上回る多くのお客様にお立ち寄りいただき、盛況のうちに展示会を終了いたしました。ブース対応を担当したメンバーからは、嬉しい悲鳴を上げるほどの反響でした。ご来場いただいた皆様に心より御礼申し上げます！   フォローアップセミナーを開催します！ AWS Summit Japan 2024でのセッションや展示ブースを通じて、お悩みを解決したい方やご興味を持たれた方々に向けて、 クラウド移行 と 生成AI に関する フォローアップセミナーを開催いたします 。 本セミナーでは、Summitでの内容をさらに深掘りし、皆様のビジネスにどのように役立てるかについて詳しくお話しします。ぜひご参加ください！ クラウドネイティブ化にも対応！ ITX for MCP SCSK版でAWS移行を最適ルートで実現しよう SCSKのAI活用紹介セミナー ～AWSとInfoWeaveで社内チャットボットを始めよう～ このようなお悩みをおもちではありませんか？ 移行対象はDBや基幹系など様々だが、確実に移行するナレッジが不足 AWS移行後、運用やDX推進できるか不安 クラウドネイティブってなにから始めたらいいのかわからない・・・ AWSへの大規模移行やクラウドネイティブ化を最適ルートで実現するソリューションパッケージ「AWS ITトランスフォーメーションパッケージ(ITX) for MCP SCSK版」が、そのお悩み解決します。 本セミナーでは、AWS Summit Japan 2024でもご紹介したITXの事例や活用方法について、詳しくお伝えします。 お申し込みは こちら AIチャットを導入し業務効率を向上させたいと考えている中、スキルや体制の不足により、実現が難しい状況にお悩みではありませんでしょうか？ 本セミナーでは、AWSとRAG構築テンプレート「InfoWeave」を活用して社内チャットボットを簡単に始められる方法をご紹介いたします。 さらに、今年6月に開催されるAWS Summit Japan 2024のアップデート情報とあわせてAWSのAI系サービスについてもご紹介させていただきます。 社内情報を活用した生成AIを導入したい方には必見の内容となっていますので、是非ご参加ください。 お申し込みは こちら   最後に 弊社のセッションおよびブースへご来場いただいた方々、誠にありがとうございました！ 多くの皆様に会えたことをとてもうれしく思います。これからもお客様のビジネスを支援に尽力いたします。 今後ともSCSKのAWSサービスをよろしくお願いいたします。

CatoクラウドのBackhaulingという機能はご存知ですか？ 通常、Catoクラウド経由でインターネット接続をする際、トラフィックはCatoクラウドのPoPから出力されますが、Backhaulingを利用することで Catoクラウドに接続する特定サイト(拠点)から直接出力 させることができます。 今回は、Backhaulingについて解説していきます！ 「Internet Breakout」と 「Local gateway IP」 冒頭でお伝えした通り、BackhaulingをさせるとCatoクラウドのPoPではなく、Catoクラウドに接続する特定サイト(拠点)から直接インターネットに接続させることができます。 また、Backhaulingには以下の 2種類があります。 特定サイト(拠点)のSocketからトラフィックを出力させるか、 Firewallなどの特定の 機器から出力させるかにより異なります。 Backhaulingの種類とその違い Local gateway IP ： Firewallなどの既存機器 からトラフィックを出力させる場合に使用 Internet Breakout： Socket からトラフィックを出力させる 場合に使用 「Internet Breakout」は別記事でご紹介することにして、 本記事で は1つめの「Local gateway IP」についてご紹介 します！ 「 Local gateway IP」の ユースケース ※本記事では「Local gateway IP」のユースケースの一例をご紹介します。 まずは結論から。Backhaulingの「Local gateway IP」は Catoへの移行途中に活躍 します 。 現行ネットワークからCatoへ移行する際、Firewallなどのセキュリティアプライアンス機器からCatoクラウドのInternet Firewallへポリシーの移行が必要となりますが、Backhaulingを使えばこの移行作業を段階的に行うことができます。 例えば、下図のような構成の場合です。 本社内に設置された現行のFirewallを残しつつ、Firewallの上位にSocketを設置します。 この場合、支店のユーザやモバイルユーザからexample.comへのトラフィックのみを 本社 内のFirewallにて処理させることができます。 このように、Backhaulingの 「Local gateway IP」は主に 「一部トラフィックのみ、現行機器のセキュリティポリシーを適用させたい」といった場合に利用されます。 ここで注意いただきたいのは、 BackhaulさせたトラフィックもCatoクラウドを経由する という点です。 そのため、Catoクラウドのセキュリティポリシーも適用されます。 つまり、この例ですと 支店のユーザやモバイルユーザからexample.com へのトラフィックは、Catoクラウドのセキュリティチェックを突破したのちに本社のFirewallへルーティングされFirewallのセキュリティチェックが行われるという流れになります。 「Local gateway IP」の設定例 上記ユースケースを踏まえ、設定手順をまとめてみました。 構成例 今回は、下図の構成を想定します。 支店のユーザから、 example.com へのトラフィックのみをBackhaulさせ、本社のFirewallによるセキュリティチェックを適用させるというシナリオです。 設定手順 Backhaulingは下記の順番で設定をします。 Step１： Gatewayサイトの定義 →インターネット接続の出口となる拠点をGatewayサイトとして定義します。 → 今回は、Firewallが設置されている”本社”というサイトをGatewayサイトとして定義します。 Step２：Network Ruleの作成 →対象トラフィックをGatewayサイトに向けるためのルーティングの設定を行います。 → 今回は、支店のユーザから example.com へのトラフィックのみを”本社”にルーティングさせます。 Gatewayサイトの定義 設定箇所：Network＞Site＞Site Configuration＞Backhauling 「Use this site as a backhauling gateway」のチェックボックスにチェックを入れます。 「Select the destination for the traffic」の設定項目が出力されます。 ここで 「Internet breakout」か「Local gateway IP」のどちらかを選択しますが、今回は「Local gateway IP」を選択します。                 上の手順で「Local gateway IP」を選択すると、IPアドレスの設定項目が出力されます。 ここではGatewayサイト内のどの機器で処理させるかを指定します。 今回はFirewallでトラフィックを処理させたいので「172.15.21.254」を入力します。                ここまででStep1のGatewayサイトの定義は完了です。 次にStep2のNetwork Ruleの作成に進みます。 Network Ruleの作成 中国のユーザからの接続の場合や、中国の拠点をGatewayサイトとする場合は、中国のインターネット規制に違反していないことを事前に確認し、設定を行う必要があります。 設定箇所：Network＞Network Rules 「New」からルールを作成していきます。 本記事ではNetwork Rulesの詳細な説明は省略いたしますが、今回は以下の通り設定をしています。   ・Name：Backhauling test ・Rule Type：Internet ・Source：Site(支店) ・App/Category：Domain(example.com) ・Configuration    – Bandwidth priority：P255    – Priority Transport：CATO(Automatic)    – Secondary Transport：None ConfigurationのRouting Methodでは「Backhaul via」を選択します。 「Backhauling Gateway Site」の設定項目が出力されるので、+ボタンからStep1で設定したGatewayサイトを選択します。 最後に「Save」ボタンで設定保存をします。 これで設定は完了です。 補足～「Local gateway IP」×「Backhaul hairpinning」～ 上の例では、Gatewayサイトの外からのアクセスとなっておりましたが、Gatewayサイト内からでもBackhaulさせることができます。 この場合は Backhaul hairpinning と呼ばれ、一部トラフィックはPoPを介してヘアピンされ、さらにGatewayサイトに転送されます。 例えば、下図のような構成の場合です。 本社のユーザからexample.comへのトラフィックのみ赤線の経路で本社内のFirewallに転送させ、Firewallにてトラフィックの処理をさせることができます。 このように、Backhaul hairpinningも上の例と同様で、一度 Catoクラウドを経由させることで移行作業を段階的に行うことが可能です。   Backhaul hairpinningの設定方法は通常のBackhaulingの設定とほとんど変わりません。 違うところは、Network RulesのRouting Methodです。 Backhaul hairpinningの場合は下図のように「Backhaul via」ではなく「Backhaul hairpinning」を選択します。 さいごに 本記事ではBackhaulingの「Local gateway IP」についてご紹介させていただきました！ 「Internet Breakout」については、別の記事にてご紹介します。

こんにちは。SCSKのふくちーぬです。 2024/6/20(木)～2024/6/21(金)に開催されたAWS Summit Japan 2024 に参加してきました。 AWS Summit Japan | 2024 年 6 月 20 日（木）, 21 日（金） オンデマンド配信中 AWS Summit は、AWSに関して学習し、ベストプラクティスの共有や情報交換ができる日本最大級の AWS イベントです。基調講演・150 を超えるセッション、さらに 250 以上の展示やハンズオンなどのEXPOコンテンツを体験し、皆様... aws.amazon.com 認定者ラウンジ 資格取得者のみ利用できるラウンジスペースと特典の配布会場です。 全冠の旨を伝えると、「おめでとうございます！」と言って貰えました。なんだか恥ずかしかったです（笑） SAP,DVA,SOAのステッカーとボトルは既に配布終了していました。。皆さんのAWS認定の注目の高さが分かります。 EXPO - AWS Summit Japan | AWS AWS Summit は、AWSに関して学習し、ベストプラクティスの共有や情報交換ができる日本最大級の AWS イベントです。 aws.amazon.com SCSKブース 弊社のブースにも立ち寄ってみました。 生成AIを活用したRAGソリューション（InfoWeave）、IoTを活用した製造業向けデジタル化ソリューション（Duetics）等、見どころたっぷりの展示やミニセッションでした。 生成AI RAGソリューション InfoWeave｜SCSK株式会社 生成AI RAGソリューション（InfoWeave（インフォウィーヴ））は、S-Cred⁺ ※ の生成AIオプションサービスです。 www.scsk.jp Duetics（デュエティクス） Duetics（デュエティクス）は、製造現場のデジタル化を支援するトータルソリューションです。製造業のお客様が求める高速かつ高い柔軟性を持つクラウドのデータ分析アプリケーションをはじめ、現場からクラウドへの直結ネットワーク、そして現場でのデ... www.scsk.jp 今年のAWS Summitは、AWS社含めたどのパートナー企業も生成AIやIoT,データ活用にかなり力をいれていました。 大規模クラウドインフラ設計・構築案件の歩き方 AWS社によるセッションです。 インフラ構築プロジェクトに参画している私としては、今回一番楽しみにしていたセッションとなります。 大規模クラウドインフラ設計・構築案件の歩き方 クラウド技術のコモディティ化により、エンタープライズ分野では近年、AWS 上での大規模なアプリケーション開発が一般的になりつつあります。これを支えるクラウドインフラ設計についても、求められる非機能要件の高度化と関連する AWS サービスの多... japansummit.awslivestream.com 聴講者として以下を想定しているそうですが、AWSに限らず全エンジニアにおすすめしたいコンテンツとなっています。 　概要：大規模クラウドインフラの設計・構築案件で得た知見や学びが体系的にまとまっている 　想定聴講者：インフラ設計発注者・受注者・内製担当者 設計 設計の骨組みづくり 以下は簡単なサンプルですが、インフラ設計書の目次となります。配属当時に知っていたら、どんなに助かったことかと思いました。 設計書一覧は可能な限り詳細に記載することで、バイネームで担当者を割り当て責任所在を明確にすること 設計事由を残すことで、設計の見直しができる状態にしておくこと 詳細設計書は、人へ分かりやすく伝えるために構築時点では詳細設計書+IaC。それ以降は、IaCを正とすること アプリ/インフラチームの責任分界 どこまでインフラチームまでの担当で、どこからアプリチームの担当であるか線引きすることはなかなか難しいですよね。 選定した開発方針とガバナンスを元に、要件に応じてインフラ/アプリチーム相互に議論して線引きを決めること コーディングルール プログラム言語で記述するのと同じくIaCでも、コーディングルールを決めておかないと品質低下につながります。 IaCにもコーディングルールは必要である（利用ツール、命名規則、スケルトンコードの利用等） 静的解析 IaCコードは、デプロイ前に必ず事前にチェックしておかないとデプロイ時に意図しないエラーやリソースが作成されるので留意しましょう。 書式のチェック(cfn-lint)、セキュリティの強制(cfn_nag)を実施するべき 構築 コスト管理はいますぐはじめる 開発開始時点で始めることが鉄則である（コスト異常検知や利用状況に気づけるように、最低限Budgets,Cost Explorerを導入しておくべき） クリティカルパスの特定 大規模/本番構築はIaCのみでは完結しないため、どのタスクがどの方法で構築することが合理的なのか、リードタイムはどれくらいなのか設計段階時に調査しておくべき 展開手順の整備 IaCコードのみに着目されがちですが、デプロイは繰返し実施されるため、更新手順や削除手順等のドキュメントを整備しておくことも忘れてはいけません。 IaC/手動/申請系を区別し、時系列や依存関係を踏まえて第三者でも分かりやすい表現でドキュメントを作成すること クラウドリソースのテスト 最後にテストについてです。 最低限、実環境・疎通性・性能の3要素に焦点を当ててテストを実施するべき Serverlesspresso – コーヒーをサーバレスとともに – カフェの注文システムをサーバレス構成で実装し、実際にコーヒーまで頂くことができるブースです。 Serverlesspresso バリスタの舞台裏 ~Happy Coffee, Happy Coding ! ~ - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS スマートフォンから注文できるコーヒー カウンター用のマルチテナント・イベント駆動型サーバーレス アプリケーション "Serverlesspresso" を提供する背景とその仕組みをご紹介します。 aws.amazon.com 5分間で10杯までしか注文を受け付けないことで、バリスタがきちんとお客さんを捌くことができます。 さすがにお客さんが増えてくると、QRコードの読み取りの待ち時間が増えているようでした。1人当たりのバリスタの処理時間をシステムの処理時間制約としている点が興味深かったです。   何とか注文できました。 無事エスプレッソを飲み、一息つくことができました。 『たまごっち』シリーズの進化と、AWS IoTで築いた 『Tamagotchi Uni』で つながる世界 続いてバンダイ様のセッションです。みなさんご存じ『たまごっち』の裏側の紹介です。 運用管理の負荷軽減と開発スピードを上げるために、サーバレスサービスをフル活用し設計しています。 IoTを利用する上で、重要な課題であるファームウェアのアップデート課題の向き合い方が非常に勉強になりました。 以下の2つを実践することで、解決していました。 アップデート対象機器に優先順位を付ける AWS IoT Device Managementの機能であるDynamic Groupの利用 この結果、世界中の皆さんの手元にあるどの『たまごっち』も仲間外れにされることなく、最新機能が配信されたと同時に遊ぶことが可能になっているんですね。 最後に いかがだったでしょうか。AWS Summit の現地レポートをお届けしました。 現地開催は、AWSの熱気や技術の面白さを生で感じ取ることができる良い機会だと改めて認識しました。 個人的には、7月発売予定の『たまごっち』が待ち遠しいです。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

こんにちは、ひるたんぬです。 先日AWS Summit Japanに初参加してきました。 最初から最後まで、その規模の大きさに圧倒され、あっという間に一日が経っていました。 参加レポについてはTechHarmonyにおいても他の方が書かれると思うので、今回はサミットに参加して、私がふと思った点について書こうと思います。 技術的な内容はありませんので、寝る前の読み物として…などで読んでいただけますと幸いです。 思ったこと AWS Summitの基調講演や各セッションを見ていると、多くのセッションでアーキテクチャの説明が行われていました。その際に、 〇〇はAPI Gatewayを通してアプリケーションからのアクセスを可能にしています。 ここの部分についてはサーバレスにて設計しています。 などの説明と同時にアーキテクチャ図が投影されていました。 これを見ながら説明を聞くと、「こういう構成をしているのか～」や、「ここってこうじゃないの、なんでだろう…」と、各セッションの取り組みをより深く理解することができるなぁ～と感じました。 （なんとなくでも、やっていることや構成が理解できるようになってきたのが嬉しい今日このごろです。） と同時に、それぞれのセッションで投影されるアーキテクチャ図のスタイルに少なからず違いがあり、「標準的な書き方やガイドラインって何かあるのかな？」と漠然と思ったので、調べてみました。   結論 ありました。それも結構細かったです。びっくりしました。   具体的には？ AWS アーキテクチャアイコンの配布サイト にてガイドラインを確認することができました。 以下にその内容についてまとめていきます。 ガイドラインはすべて英語で記載されています。 私がまとめた内容と実際のガイドラインに齟齬がある場合がありますので、厳密に確認が必要な場合などは、公式ガイドラインをご確認ください。 「Release 18-2024.02.06」の資料を基に作成しております。 アーキテクチャ図の作成手順 カラーテーマを選ぶ アーキテクチャアイコンには、背景色のタイプに合わせて「ライトテーマ」と「ダークテーマ」の2つが用意されています。作成物に合わせてより適切な方を選択します。 「ライトテーマ」はWebサイト、「ダークテーマ」はプレゼン資料で用いられる傾向があるようです。 リージョンやVPC（”Groups”と表現されています。）を配置する 大枠の構造として、グループを配置します。 アーキテクチャアイコンやリソースアイコンを配置する アイコンセットから必要なアイコンを選択し、適切な位置に配置します。 矢印でそれぞれのアイコンを結ぶ 矢印でアイコンを結び、ワークフローを表現します。 【オプション】ステップを追加する アーキテクチャ図内に番号を付与することで、手順をわかりやすく表現できるようにします。 縦長なレイアウト（Wordやブログ記事など）の場合 この場合はPowerPointのスライドを縦長に設定し、アーキテクチャ図を作成します。 PowerPointで「新しいプレゼンテーション」を作成する スライドのサイズを変更する 「デザイン」→「スライドのサイズ」より「ユーザー設定のスライドのサイズ」を押下します。 幅に「6.5″」、高さに「8.75″」と入力し、「OK」を押下します。 背景色は白色に設定しておきます。 ガイドラインに従いアーキテクチャ図を作成する 上記「アーキテクチャ図の作成手順」を参考にしてください。 図として貼り付ける 作成したアーキテクチャ図をすべて選択しコピーし、Wordにて「図として貼り付け」をします。 ブログ記事への貼り付け時や画像ファイルで保存したい場合などは、すべて選択したあとに右クリック→「図として保存」を選択することで可能です。 “Training and Certification” の場合 過去のガイドラインでは、スライド投影時のガイドラインとして記載されていたようですが、タイトルが変更されています。直訳すると「トレーニングと認定」ですが、これが何を指しているかはガイドラインから理解することはできませんでした… 過去のガイドライン記事の参考： 株式会社BeeX 「AWSのアーキテクチャ作図ガイドラインを確認してみた」 テキストサイズと色について テキストサイズは「16pt」で「黒色」にしてください。 アイコンサイズと色について アイコンサイズや色は変更しないでください。 線の太さと色について 線の太さは「2pt」で、色は変更しないでください。 アイコンや線の色を変更しない理由として、アクセシビリティの検証を行っているためとありました。 各種デザインの使用上の注意 以降では、種類別にアーキテクチャ図に挿入する上での注意事項が記載されています。 グループ（VPC, サブネットなど） サイズの変更方法 枠の右下を選択して実施してください。 ネスト(入れ子に)する場合 それぞれのグループの線の間に最低でも0.05″の間を空けてください。 引用：AWS 「 AWS アーキテクチャアイコン PowerPoint用ツールキット 」 プリセットに適したものがない場合は”genetic group”を使用すること 必要に応じて自分でカスタムグループを作成すること カスタムグループの雛形が用意されているため、アセットにあるアイコンと入れ替えて使用します。 入れ替えるアイコンはサイズ(ファイル名などに”32″とあります)や拡張子(.svg)の指定があります。 未承認のAWSアイコンを使用してグループを作成すること グループに設定するアイコンのサイズを変更すること アイコン サイズの変更 プレゼンテーションで使用する場合のみ拡大・縮小が許可されています。 縦横比を維持するため、Shiftキーを押下したままサイズの変更をしてください。 プレゼンテーション以外の用途では、サイズの変更はしないでください。 アイコンのトリミングをすること アイコンを反転・回転すること アイコンの形を変えること 矢印 プリセットを使用 矢印はプリセットよりコピーして使用してください。 サイズ（長さ）を変更する場合はShiftキーを押下したまま行ってください。 → 同一直線上でサイズ変更ができます。 可能な限り直線と折れ線（直角）で各アイコンをつなぐこと できない場合は、対角線（斜め）でつないでも良い プリセットの矢印の形状が利用できない・存在しない場合はデフォルトの形状で使用すること プリセットやデフォルト以外の形状の矢印を使用すること アイコンラベル フォントについて 書体は「Arial」で、フォントサイズは「12pt」にしてください。 ラベルの改行について サービス名は2行以内に収める必要があります。 また、”AWS”や”Amazon”と付く場合には、そのあとに続くサービス名を同じ行に含めなければなりません。そして、単語の途中で改行することは禁止されています。（下図参照） 引用：AWS 「 AWS アーキテクチャアイコン PowerPoint用ツールキット 」 ドキュメント内で正式名称に言及せずに、略称のみ記載すること 略称が重複すること 例）ELB：Elastic Beanstalk, Elastic Load Balancing 番号吹き出し スタイルについて 黒丸に白色の字で番号を記載します。（アーキテクチャ図内で目立つようにするため） アーキテクチャ図の複雑さに応じて2種類のフォーマットが用意されています。 できる限り直線的に番号を順に振ること 左から右、上から下、時計回りなどに振ってください。 吹き出しの位置はなるべく統一すること 同一アーキテクチャ図で、サイズの異なる吹き出しを使用すること 文字や記号など、数字以外をラベルとして使用すること 吹き出しのサイズを手動で変更すること 新しい形の吹き出しを作成すること   おわりに 今回は技術的な内容とは少し離れましたが、AWSに触れる方の多くは一度は見ているであろうアーキテクチャ図について、そのお作法があるということを改めて知ることができました。今まで業務やこのブログにおいて何回かアーキテクチャ図を書いていましたが、ガイドラインに準拠していないところだらけで、少し恥ずかしく思っております。 ガイドラインに沿って作成することで、自然と見る相手にも分かりやすいアーキテクチャ図になると思うので、作図の練習を通してこのガイドラインを身につけていきたいなと思いました。   余談ですが… この度 AWS Japan APN ブログ や 弊社プレスリリース でも発表がありましたが、私(蛭田)は「2024 Japan AWS Jr. Champions」に選ばれました！ 入社から一年と少し、そしてAWSに触れ始めてからおよそ半年でここに選出いただけたことはとても光栄であり、今までの取り組みを認めていただけたのだと達成感を感じております。ですが、これに満足しておしまい…では決してありませんので、限られた任期(1年)の中を後悔することのないように日々邁進してまいります。

どうもこんにちは、SCSKの齋藤です。 みなさんは先日のAWS Summit Japanに参加しましたか？ 相変わらずの熱狂ぶりがすごかったですね〜 多くのセッションを通じて学びを得れたのと、社内外多くの知り合いに再会できて、大変刺激的な時間を過ごすことができました。 また、弊社の2024 Japan AWS Jr. Championsも輩出され、一緒に写真を撮ったりして、後輩のジュニチャンができたことを強く実感しました！後輩よ、頑張ってくれ〜 さて話は本題に入りますが、先日のAWS Summit Japanのセッションの中で気になることを学びましたので、早速検証して記事にしてみました。 概要 題名にもある通り、AWS StepFunctionsから直接APIを叩くことができるというものです。 以前からAWS StepFunctionsにはAPI Gatewayの連携はありまして、API Gatewayで作成されたAPIなら直接アクセスすることはできました。しかし、サードパーティAPIについては、Lambda関数を作成してアクセスする必要がありました。 ですが、なんとサードパーティAPIへのアクセスもStepFunctionsから直接叩けるようになってたとのことです。驚きですね！ このアップデート自体は、昨年のre:invent2023で発表されたものなのでまだ半年ちょっとしか経過していません。 ちょうど、私が4月から担当しているプロジェクトでも、サーバーレス開発をしているので、役立つかも知れないと思い検証してみました！   検証内容 今回は下記のようなステートマシンとしております。 ステートマシンのワークフローの中で、APIGatewayに直接叩きに行く処理を先に2回実施し、そのレスポンスをもとに、サードパーティAPIを叩きに行くという流れとなります。 実際のプロジェクトなどで開発する場合では、リソース間の情報を連携してAPIを叩きにいくことは多いかと思いますので、こういった観点で検証してみました。   準備 今回の検証には主に下記3種類のリソースを作成します。 ① StepFunctionsステートマシン ② APIGatewayエンドポイント ③ サードパーティAPI（ApiGateway、Lambda） ①、②については、AWS側でテンプレートがあったので、それをそのまま使って構築しました。 ③については、サードパーティAPIをAPIGatewayで作成しました。（なんかややこしいですね。） APIGatewayのデプロイと、APIキーの作成、使用量の作成を行えば、実質サードパーティAPIができたも同然なので、そのAPIを叩きにいくようにしました。さらに、APIの裏側でLambdaを実装し、データの加工を少しだけ行うようにしました。 では、作成方法を解説します。   ①StepFunctionsステートマシン、②APIgatewayエンドポイント StepFunctionsのコンソール画面に行き、「ステートマシンの作成」を押下すると、テンプレート選択画面が出ます。 ここで、自分が実装したいことの類似テンプレートを選択すると、ある程度出来上がったステートマシンを見ることができます。 今回は、「API Gateway への呼び出しを行う」にチェックをつけ、次へ行きます。 テンプレートの活用方法が選択できるので、「デモの実行」を選択します。一旦ステートマシンを作成して、後ほどサードパーティAPIの処理を追加します。 今回のテンプレートは、 ① 最初のAPIGatewayでペットストアにペット商品の情報を登録（Post）し、 ② 2つ目のAPIGatewayで、ペットストアの情報を取得（Get）する 上記２つの流れのステートマシンとなっております。 次に画面が遷移するので、「デプロイと実行」をクリックし、ステートマシンの実行を行います。   CloudFormationの実行が走るので、少々待ちます。 デプロイが完了すると、実行画面が表示されます。 入力情報を作成し、「実行開始」をクリックします。デフォルトでサンプル値が用意されており、カメの商品情報を追加するデータとなっています。 実行が成功すると、画面上部に成功メッセージが表示され、ステートマシンの通過した処理を緑で表示します。 ちなみに、各アクションをクリックすると、イベント情報の詳細を確認できます。 下記２つののキャプチャは、1番最初に実行されるアクション「Add Pet to Store」の入力と出力です。 そしてさらに下記２つのキャプチャは、「Retrieve Pet Store Data」の入出力データです。入力データが、前の「Add Pet to Store」の出力データと同じになっていることを確認できますね。 出力データも長くて見切れていますが、「ResponseBody」で始まるフェーズと、「ExistingPets」で始まるフェーズがあるのを確認できます。 「ResponseBody」は新規に追加した情報で、「ExistingPets」は従来から存在しているデータのことを指していると思われます。 この後設定するサードパーティAPIは、「Retrieve Pet Store Data」の後に追加する予定のため、この出力データの一部である「ResponseBody」をサードパーティAPIのインプットにする予定です。 一旦、ここまででストップし、サードパーティAPIの作成に移ります。 ③ サードパーティAPI 先述した通りAPIGatewayとLambdaを使ってサードパーティAPIもどきを作成します。 Lambda 先にLambda関数を作成します。 サードパーティAPIの裏側で稼動するLambdaとして、今回は受け取ったリクエストをjson形式に変換し、ステータスコードとともに変換するという処理を実施します。 Lambdaのコンソール画面に移動し、「関数の作成」をクリックします。 任意の名前とランタイムで関数を作成します。今回はPythonを使います。 関数が作成されるのを確認します。 デフォルトで作成されたソースコードを少しだけ編集します。 ソースコードのjson.dumpの中身を入力値eventに置き換えます。入力値をjson形式に変換する処理を実施するためです。 下記のように変更いたら、「Deploy」ボタンを押下します。 デプロイの成功後、テストを実施するため、上記画面の「Test」を押下し、テンプレートを作成し、保存します。 その後、再び「Test」ボタンを押下して、テストを実施します。 json形式に変換してステータスコードとともに表示するので、下記のような結果になれば作成成功です！   APIGateway APIGatewayコンソールに移動し、「APIを作成」をクリックします。 APIの種類を選択する画面で、「REST API」を選択します。   「新しいAPI」を選び、APIエンドポイントタイプを「リージョン」にして、任意のAPI名で作成します。 そうすると、空のAPIが作成されました。 リソースの作成 空のAPIができたので、次はリソースを追加します。 先ほどの空のAPI作成画面の左上に「リソースを作成」というボタンがありますので、そこをクリックします。 リソースパス/の配下に、任意のリソース名を作成します。 作成されると、リソース欄に表示されるのを確認できます。 メソッドの作成 その後、同じ画面の「メソッドを作成」をクリックし、APIが叩かれた後の処理を定義します。 メソッドタイプをPOSTにし、統合タイプを「Lambda関数」に設定します。 Lambda関数は選択式なので、先ほど作成したものを選びます。 後の設定はデフォルトで良いため、画面下の「メソッドの作成」を押下します。 作成が完了すると、メソッド情報が表示されるようになります。 テスト API動作のテストを行います。 先ほどの画面の「テスト」というボタンを押下すると、テスト作成ができます。 リクエスト本文に{“test”:1}と入力し、テストの作成を行います。 テスト作成後にすぐにテストされるので、結果を確認します。 いいですね！ステータスコード200とjson化された入力値が返されており、先ほど作成したLambda関数と統合されているのがわかります。 APIキーの作成 APIリクエストにはAPIキーによる認証をした方が望ましいので、APIキーを作成します。 まず、作成したAPIの画面の左のバーから、「APIキー」を選択します。 その後の画面から、「APIキーを作成」を押下します。 任意の名前でAPIキーを作成します。 保存後に、APIキーが作成されていることを確認します。 なお、APIキーの四角の部分をクリックすると、APIキーがクリップボードにコピーされます。後ほど必要なので、手元に控えておいてください。 リクエストとAPIキーの結び付け リクエストにAPIキーを結び付けて、接続の際に認証するようにします。 まず、APIのトップ画面に遷移し、画面左の緑のPOSTをクリックします。そうすると、下記のような画面になるかと思います。   1番最初のリクエストのところでAPIキーが欲しいため、「メソッドリクエストの設定」の編集ボタンをクリックします。 「APIキーは必須です」をクリックし、保存を押下します。 デプロイ APIそのものは整ったので、公開する準備を行います。 再び、作成したAPIのトップ画面へ遷移します。 その画面の「APIをデプロイ」を選択します。 ステージを作成するため、下記情報を入力します。 今回は開発環境ということでdevというステージ名にしております。 入力後、デプロイを押下します。 使用量プランの設定 API公開前最後の設定を行います。 再び、作成したAPIの画面の左のバーから、「使用量プラン」を選択します。 その後の画面で「使用量プランを作成」をクリックします。 スロットリングやクォータの設定をできますが、今回はどちらもチェックを外して、「使用量プランを作成」をクリックします。 作成後、使用プランのページに遷移するので、ステージとAPIキーを追加していきます。 まずは、「関連づけられたステージ」→「ステージを追加」をクリックします。 APIの部分は作成したリソース名を選択し、ステージの部分は作成したステージを選択し、追加を押下します。 再び使用プランのページに戻り、今度は「関連づけられたAPIキー」にスイッチし、「APIキーを追加」を押下します。 既存のキーから、事前に作成したAPIキーを選択し、追加します。 これにてAPIを公開することができました。   StepFunctionsの編集 作成したサードパーティAPIをStepFunctionsに組み込みます。 事前に作成したStepFunctionsのページを開き、画面右上の編集ボタンを押下します。 編集画面の左側から「Call third-party API」を選択し、２つ目のAPIGatewayの後にドラッグ＆ドロップします。 挿入後、API接続の設定画面が表示されるので、設定を諸々入力します。 APIエンドポイント 作成したサードパーティAPIのURLを入力します。 メソッド 今回はPOSTするようにサードパーティAPIを作成したので、POSTを選択します。 Authentication APIキーの保存先の参照を設定します。これはEventBridgeConnectionというリソースを経由してSecretsManagerに保存されるため、そのリソースを作成します。「新しい接続を作成」をクリックしてください。 接続名は任意の名前を設定し、送信先タイプを「その他」で選択し、認証の部分で「APIキー」を選択します。 ヘッダー名には、 x-api-key と入力してください。 ヘッダー値には、APIキー作成時に控えておいた、APIキーを入力します。 作成後、再びStepFunctionsの画面に戻ります。 Authenticationの選択肢に、先ほど作成したものが追加されるので、選択します。 その後、リクエスト本文を入力します。 今回は、前のAPIGatewayの処理のレスポンスを受け取り、それをサードパーティAPIのリクエストにするため、「実行時に状態入力からリクエスト本文を取得」を選択し、「 $.ResponseBody 」と入力し、保存を押下します。 これは、先述した「①StepFunctionsステートマシン、②APIgatewayエンドポイント」の最後の方で、「Retrieve Pet Store Data」の出力の一部である「ResponseBody」をサードパーティAPIの入力にすると記載しましたのを反映してます。 先頭に$.をつけると、入力値のjson辞書から該当のKey値（今回でいうとResponseBody）の値を取得する設定を行うことができます。 もちろん、「ExistingPets」を入力としたい場合は、「$.ExistingPets」とすることで正しく渡されるのを確認できます。 保存が完了したら、画面右上から「終了」を押下します。 必要権限の設定 最後に、StepFunctionsに必要な権限を設定します。 ステートマシンの画面からIAMロールARNをクリックし、IAMの画面に遷移します。 最初に作ったStepFunctionsはAPIGatewayを直接叩くのみの権限しかないため、サードパーティAPIを叩くのに必要な権限をインラインポリシーで追加します。 下記のようなポリシーを作成してポリシーをアタッチします。 権限付与に参考にしたブログは下記のとおりです。 Third-party API integration in AWS Step-Functions The objective of this blog is to give a basic understanding of how Step Functions incorporate third-party API integratio... community.aws   ステートマシンの実行 長かったですが、これでサードパーティAPIを叩く準備はできました。 今一度ステートマシンのページに移動し、画面右上の「実行を開始」をクリックします。 入力データを求められるので、最初のStepFunctions作成した時の入力データを参考に新しいペット情報を入力し、「実行を開始」ボタンを押します。 実行された後、ステートマシンのステータスを確認できるので、全て緑になっていれば成功です。 試しに、「Call third-party API」をクリックすると、画面右にデータが表示されます。 出力タブをクリックし、下にスクロールすると、ResponseBodyに1番最初に入力したデータが表示されております。 サードパーティAPIの裏のLambdaで処理された値なので、ResponseBodyの中にステータスコードとjson化された入力データが入っているのを確認できます。 これにより、前の処理で実行された APIGatewayの値をインプットに、サードパーティAPIにアクセスすることができると確認できました。   まとめ 今回はStepFunctionsからサードパーティAPIへの接続を試行してみました。 今回は検証初期段階ですが、私が現時点で気になることとして下記3点が挙げられます。 出力の整形はどこまで可能か？ 前後にLambdaを挟んでも情報を正しくやり取りすることは可能か？ APIエラー時の扱いもどこまで柔軟に設定が可能か？ 上記はこれから検証することとして今回のブログは一旦終わりにしたいと思います。 個人的な所感としては、APIのレスポンス情報を元に複雑なメッセージ整形処理を必要とする場合、Lambdaの方が適しているのかなと考えております。 APIを叩いて、その情報をほとんどそのまま次の処理に渡すなどの場合は、Lambdaではなく、この機能を活用した方が開発生産性が上がるかもしれません。