こんにちは、SCSKの坂木です。 本記事では、 Zabbixサーバのインストールを自動化するシェルスクリプト(RHEL系OS/PostgreSQL編)を紹介 します! 検証環境 今回、検証に使用した環境は以下の通りです。 コンポーネント バージョン/種類 備考 OS Amazon Linux 2023 RHEL系のディストリビューション データベース PostgreSQL Zabbixで広く利用されているデータベース Zabbix Zabbix7.0 LTS 2025/08時点での最新の長期サポート版 この構成に基づき、本ブログで公開するスクリプトは 「RHEL系OS + PostgreSQL」の環境に、Zabbix 7.0 LTSをインストール するものとなっています。 もし異なるOS(Ubuntuなど)やデータベース(MySQLなど)をご希望の場合は、一部カスタマイズが必要となりますので、あらかじめご了承ください。 前提条件 PostgreSQLサーバが起動していること 本スクリプトはZabbixサーバのコンポーネントをインストールし、DBに接続する設定を行いますが、PostgreSQLサーバ自体のインストールや起動は行いません。あらかじめMySQLが利用可能な状態にしておいてください。 OSがZabbixサーバのバージョンに対応していること Zabbixサーバはバージョンごとに公式にサポートされるOSが定められています。対応しているOSのバージョンは こちら を確認してください。 RHEL系のOSであること このスクリプトは、パッケージ管理にdnfコマンドを利用するなど、RHEL系のOSに特化して作成されています。 インストールスクリプト スクリプトはこちらになります。リポジトリのインストール元は こちら を参照しOSに合わせて変更ください。 #!/bin/bash set -e # 1. ZabbixがPostgreSQLデータベース接続用に使うパスワード ZABBIX_DB_PASS='<PostgreSQLのzabbixユーザのパスワードを入力してください>' echo "--- Zabbixリポジトリの追加とパッケージのインストールを開始します ---" rpm -Uvh https://repo.zabbix.com/zabbix/7.0/amazonlinux/2023/x86_64/zabbix-release-latest-7.0.amzn2023.noarch.rpm dnf clean all dnf install -y zabbix-server-pgsql zabbix-web-pgsql zabbix-apache-conf zabbix-sql-scripts zabbix-agent echo "--- Zabbix用データベースとユーザーを作成します ---" sudo -i -u postgres psql -c "CREATE USER zabbix WITH PASSWORD '${ZABBIX_DB_PASS}';" sudo -i -u postgres createdb -O zabbix zabbix echo "--- Zabbix初期スキーマとデータをインポートします ---" zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | sudo -u zabbix psql zabbix echo "--- Zabbixサーバーの設定ファイル(/etc/zabbix/zabbix_server.conf)を編集します ---" sed -i "s/^# DBPassword=/DBPassword=${ZABBIX_DB_PASS}/" /etc/zabbix/zabbix_server.conf echo "--- 関連サービスを再起動し、自動起動を有効化します ---" systemctl restart zabbix-server zabbix-agent httpd php-fpm systemctl enable zabbix-server zabbix-agent httpd php-fpm echo "--- Zabbixのセットアップが正常に完了しました ---" 適当なディレクトリに配置してスクリプトを実行してください。実行前にはスクリプト内容をご確認いただき、ご自身の責任で実施いただければと思います。 [root@ip-10-0-30-49 work]# ll total 4 -rwxr-xr-x. 1 root root 1385 Sep 1 06:43 zabbixinstallscript.sh [root@ip-10-0-30-49 work]# ./zabbixautoinstall.sh 実行確認 スクリプト実行後、問題なくzabbixが起動しているか以下のポイントを確認します。 systemctl statusコマンドでzabbixサーバ、zabbixエージェントが起動していること # systemctl status zabbix-server ● zabbix-server.service - Zabbix Server Loaded: loaded (/usr/lib/systemd/system/zabbix-server.service; enabled; preset: disabled) Active: active (running) since Mon 2025-09-01 06:44:39 UTC; 18min ago # systemctl status zabbix-agent ● zabbix-agent.service - Zabbix Agent Loaded: loaded (/usr/lib/systemd/system/zabbix-agent.service; enabled; preset: disabled) Active: active (running) since Mon 2025-09-01 06:44:39 UTC; 18min ago zabbixのwebインタフェースにアクセスできること まとめ 本記事では、スクリプトを実行するだけでZabbix 7.0を自動インストールする手順をご紹介しました。なお、本記事で提供するスクリプトは、以下の環境を前提としています。 OS: RHEL系 (Rocky Linux, AlmaLinux など) データベース: PostgreSQL Zabbixバージョン: 7.0 もし上記以外の環境(例: Ubuntu, MySQL)でZabbixを構築されたい場合は、本スクリプトは対応しておりませんのでご注意ください。その場合は、Zabbix公式ドキュメントを参考に手動でインストールをお試しいただくか、OS/データベースに合うスクリプトをご利用ください。 OS:RHEL系 / データベース:PostgreSQLのスクリプトは以下記事に記載があります。 スクリプトを用いてZabbixサーバのインストールを自動化してみた-RHEL系OS/MySQL編- Zabbixサーバのインストールを自動化するシェルスクリプトを紹介します!初心者でも簡単に短時間でZabbixサーバの構築が可能となります。スクリプトを用いた構築で効率化をしましょう! blog.usize-tech.com 2025.09.02
こんにちは。SCSKの磯野です。 Google Cloud では、複数プロジェクトのログを集約・可視化する方法として「 ログスコープ 」と「 ログシンク 」の2つが提供されています。 では、組織全体のログ監視を設計する際、どちらを選択すべきなのでしょうか。 本記事では両者の仕組みとユースケースを比較し、最適な選択肢を導くためのポイントを解説します。 プロジェクトをまたいだログの閲覧 ログシンク(ログルータによる集約シンク)とは 集約シンクの概要 | Cloud Logging | Google Cloud ログストレージを集中管理できる集約シンクについて学びます。 cloud.google.com 集約シンクを使うと 組織やフォルダ単位でログを一元的に集めること ができます。 集約シンクには2つのモードがあります。 インターセプトモード 集約対象のログを一か所に移動するため、元のプロジェクトからログが見えなくなる。権限管理には注意が必要 ログの重複保管を防ぎ、コスト削減になる 非インターセプトモード(デフォルト) 集約対象のログを元のプロジェクトと集約先の両方に保存 プロジェクト担当者・集約先担当者の両方がログを確認できる ログの重複保管が発生するため、コストがかかる なお、集約シンクを使わずに個別プロジェクトごとにログルータを設定することも可能です。 ログスコープとは ログの実体を移動することなく、複数プロジェクトのログを まとめて参照できる機能 です。 コストは安価ですが、あくまで「ビュー」のような存在であり、後述する監視用途では制約があります。 複数プロジェクトのログ監視ではどちらを採用すべき? 前提 複数のプロジェクトのログ監視を行うにあたり「 ログ監視を行うプロジェクトを一か所に集約できること 」を目指します。 結論:ログシンクを採用すべき 理由は以下の通りです。 ログベースのアラートはログスコープに対応していない 以下ドキュメントにもあるように、ログベースのアラートポリシーは「そのポリシーを設定したプロジェクト内のログ」にしか作用しません。 そのため、ログスコープを使って複数プロジェクトのログを参照しても、アラートポリシーは動作しません。 Log-based alerting policies don’t honor the scope setting in the Logs Explorer page. Configure log-based alerting policies | Cloud Logging | Google Cloud cloud.google.com ログシンクなら対応可能 ログシンクを使えば、集約先のプロジェクトにログをコピーできるため、そのプロジェクトを基点にアラートポリシーを作成できます。 Google Cloud における監視方法について- モニタリングとロギング Google Cloudにおける監視はログ監視とメトリクス監視の2種類に分けることができます。Cloud Loggingの使い方、Cloud Monitoringにおけるクエリの書き方、Terraformでアラート実装方法等をご紹介します。 blog.usize-tech.com 2025.06.09 ログスコープ/ログシンクの比較・ユースケース 項目 ログスコープ ログシンク 設定方法 △ プロジェクトレベルで指定可能 フォルダ配下のプロジェクトを動的に指定できないため、大規模プロジェクトの管理には不向き ○ フォルダレベルで指定可能 コスト ○ 参照のみなので安価 △ ログがコピーされるため転送先に応じてコスト発生 クォータ △ 1つのログスコープあたり最大5プロジェクトまで 参考: クォータ ○ 記載なし(プロジェクトや転送先に依存) 監視設定 × ログベースのアラートポリシーには利用できない ○ 可能(Cloud Monitoringのアラートなどに活用可能) 主なユースケース プロジェクト間のログをまとめて 横断的に調査・分析 したい場合 開発・検証などコストを抑えたい場合 アラート検知や監査対応 が必要な場合 ログを長期保存(BigQuery/Cloud Storage)したい場合 セキュリティや運用要件で 外部に転送(Pub/Sub → SIEMなど)したい場合 まとめ いかがだったでしょうか。 今回は、Google Cloud における ログスコープとログシンクの違い 、そして ログ監視を設計する際にどちらを使うべきか を整理しました。 結論として、 監視やアラート設定を前提とするなら「ログシンク」 を採用するのが実運用上は有効です。 一方で、コストを抑えて横断的に参照したいだけなら「ログスコープ」も選択肢になります。 本記事が、みなさまのログ設計の参考になれば幸いです。
こんにちは。SCSKの津田です。 今回は、Azureの環境で仮想IPアドレスをどのように機能させるかについてご紹介します。 クラウド環境では、オンプレミスで当たり前に使えていた「仮想IP(VIP)」が、実はそのままでは使えないケースが多くあります。 AWSでは、第4回でご紹介したように、EC2やRoute 53といったリソースを活用することで、クライアントからの接続を実現していました。 【LifeKeeper】AWSでは仮想IPアドレスが使えない!?をこうして解決する!! – TechHarmony では、Azureではどうでしょうか? Azureでは、AWSとは異なるアプローチで仮想IPを実現しています。 本記事では、実際に仮想IPを実装し、簡単な動作確認を行ってみました。 Azure環境では仮想IPが使えない?ではどうする? 仮想IPは、HAクラスタ構成において非常に重要な役割を果たします。 仮想IPは現在稼働しているノード(アプリケーションが実行されているノード)に常にマッピングされ、クライアントは常にこの仮想IPアドレスでアクセスできることで、障害時でもクライアントは意識することなくシステムを利用することができます。 しかし、Azure の仮想ネットワークでは LifeKeeper で設定した仮想IPがオンプレや仮想環境のようには認識されません。 そのため、通常では仮想IPを使用したネットワーク通信や保護はできません。 この問題を解決するため、 Azureではロードバランサー、LifeKeeperのLB Health Check Kitを使用することで仮想IPを機能させます。 クラスタを同一リージョン内に構築する場合、 内部ロードバランサー(Internal Load Balancer、ILB)でフロントエンドIPを設定し、バックエンドプールに稼働系ノードと待機系ノードのNICの IP アドレスに設定し、そのIPアドレス宛に正常性プロープを行います。 ILBのフロントエンドIPは仮想IPとして活用でき、クライアントからの仮想IP宛のネットワーク通信はILBに到達し、クラスタに負荷分散されます。負荷分散は正常性プローブで応答が返り正常な結果となるノードにのみ行われます。 この正常性プローブに対しノード側で応答するのがLB Health Check Kit (LB Health Checkリソース) の機能であり、 LifeKeeperによってLB Health Check Kitはアクティブ側のみで稼働し、正常性プローブに応答する状態となっています。 よって、 クライアントからのネットワーク通信はILB経由で常にアクティブなノードに転送され、LifeKeeperによってアクティブノードに付与された仮想IPで接続要求を受信し応答を返します。 SIOSオンラインマニュアルには、仮想IPアドレスを利用したクライアントからの接続フローがイメージ図付きで解説されています! ■Windows Azure 特有の設定について – LifeKeeper for Windows LIVE – 8.11.0 ■Linux Azure 上の LifeKeeper 特有の設定について – LifeKeeper for Linux LIVE – 9.9.1 正常性プローブとは? 「プローブ(probe)」とは、「探査」を意味する用語であり、Azure 正常性プローブとは、バックエンドプールの正常性を監視するためのヘルスチェックのような機能です。 正常性プローブへの応答がない仮想マシンについては適切に検出し、新しい接続の送信を停止します。 LB Health Check Kitとは? クラウド環境でロードバランサーの負荷分散対象インスタンスへのヘルスチェックプローブを待ち受けて応答する仕組みを提供します。 参考: https://docs.us.sios.com/sps/8.11.0/ja/topic/lifekeeper-for-linux-lbhc 検証した構成 今回は実際に仮想IPを実装してみました。 以下はノード・ネットワーク構成のイメージ図となります。 ※「LBHC」= LB Health Checkの略 ■OS:Windows Server 2022 Datacenter ■LifeKeeper:LifeKeeper for Windows 8.11.0 ※Windowsでの注意点として、LifeKeeperで仮想IPを付与するNICとILBのバックエンドプールとして指定するNIC(IP)を別にする必要があります。 https://docs.us.sios.com/sps/8.11.0/ja/topic/microsoft-azure-validation-guide?q=azure docs.us.sios.com 仮想IP実装に必要となる設定 Azureで仮想IPを機能させる場合、ロードバランサー、IPリソース、LBHCリソースの作成がポイントになります。 今回の検証にあたって作成した内容をそれぞれご紹介します。 ※WindowsOSで検証を行った際の内容となります。 ※環境により各設定値は変わる場合があります。 ロードバランサー作成 前提:仮想ネットワーク、仮想マシンの作成が完了していること。 Azure Portalの ホーム> 負荷分散とコンテンツ配信 > ロードバランサー の画面から[作成する]をクリックし、 [Standard Load Balancer]を選択 。 以下の通り各項目を記入、選択し、[次:フロントエンドIP構成>]をクリック。 ※ 今回は内部ロードバランサーを使用するため、[種類]は[内部]を選択。 [フロントエンドIP構成の追加]をクリックすると、画面右に「フロントエンドIP構成の追加」が表示されるため、 以下の通り各項目を記入、選択した後、[保存]⇒[次:フロントエンドIP構成>]をクリック。 ※ このクラスタへの仮想IPでの接続時は、この[IPアドレス]を仮想IPとして利用。 [バックエンドプールの追加]をクリック。 [バックエンドプールの追加]で以下の通り各項目を記入、選択し、[追加]をクリック。 画面右側に「バックエンドプールへのIP構成の追加」が表示されるため、バックエンドプールに指定するIPアドレスを選択し[追加]⇒[保存]をクリック。 ※ Windowsでは仮想IPリソースで使用するNICとは異なるNICのIPアドレスを選択。 [次:インバウンド規則>]をクリック。 [負荷分散規則の追加]をクリックすると画面右側に[負荷分散規則の追加]が表示される。 [正常性プローブ]で[新規作成]をクリックし、以下の通り各項目を記入し、[保存]をクリック。 ※ [ポート]は正常性プローブを行うポートの宛先となる。クラスタ内のノードで使用可能な任意のポートを指定。 画面右側の[負荷分散規則の追加]に以下の通り各項目を記入し、[保存]⇒[確認及び作成]をクリック。 デプロイを完了させる。 ※1、※2 クラスタ内のアプリケーションが使用するポート番号を指定。(今回は検証の為IISを導入するためポート80(HTTP)を指定。) ※3 クライアントからクラスターへ向けた通信を、IP リソース(VIP)宛のパケット通信とする必要があるため、[フローティングIP] は有効にする。 IPリソース作成 前提:OSの設定、LKインストール、コミュニケーションパスの作成が完了していること LifeKeeperのGUIで以下赤枠の[+]ボタンをクリックします。 ウィザードに従い、以下の表のとおり設定値を入力します。 IPアドレス(作成) プライマリサーバ LKNODE01 バックアップサーバ LKNODE02 保護するアプリケーション IPアドレス IPアドレスのタイプ 仮想IPアドレス IPアドレス 10.10.5.200 ※1 サブネットマスク 255.255.255.255 ※2 IPリソースタグ名 ip-10.10.5.200 ネットワーク接続 Ethernet 2 ※3 ローカル・リカバリー いいえ IPアドレス(拡張) サブネットマスク 255.255.255.255 ※3 ネットワーク接続 Ethernet 2 ターゲット・リストアモード 有効 ターゲット・ローカルリカバリー いいえ バックアップの優先順位 10 ※1 設定済の Azure ロードバランサーのフロントエンド IP と同じ値を使用。 ※2 ルーティングの競合を避けるため 255.255.255.255 を設定。 ※3 仮想IPを付与するNICとして、ILBのバックエンドプールに指定したNIC(IP)とは別のNICを指定。 LBHCリソース作成 前提:OSの設定、LKインストール、コミュニケーションパスの作成が完了していること LifeKeeperのGUIで以下赤枠の[+]ボタンをクリックします。 ウィザードに従い、以下の表のとおり設定値を入力します。 IPアドレス(作成) プライマリサーバ LKNODE01 バックアップサーバ LKNODE02 保護するアプリケーション LB Health Check 応答デーモンポート 12345 ※1 応答デーモンメッセージ 空欄 LB Health Checkリソースタグ名 lbhc-12345 IPアドレス(拡張) LB Health Checkリソースタグ名 lbhc-12345 バックアップの優先順位 10 ※1 ILBの[正常性プローブ]の[ポート]で設定した値を設定。 仮想IP機能検証 クラスタ内の各ノードでIISの導入およびIISリソース作成を行い、仮想IPの簡単な動作検証を行いました。 事前準備 クラスタ内各ノードのIISのドキュメントルートに、サーバ名を記載したテストページ(htmlファイル)を格納します。 <LKNODE01 %SystemDrive%\inetpub\wwwroot\test_page.html> <LKNODE02 %SystemDrive%\inetpub\wwwroot\test_page.html> 動作確認 想定 :クライアント端末から仮想IPにアクセスすると、LKNODE01とLKNODE02のどちらがアクティブかスタンバイかに関係なく、常にアクティブ側のテストページが返される。 LKNODE01がアクティブ クライアント端末から仮想IP宛にIISのテストページにアクセスすると、想定通りLKNODE01のテストページが表示されました。 LKNODE02がアクティブ クライアント端末から仮想IP宛にIISのテストページにアクセスすると、想定通りLKNODE02のテストページが表示されました。 どちらも想定通りの結果となり、仮想IPが機能していることが確認できました! ちなみに… lbhcリソースを削除して、IISのテストページにアクセスしてみたところ、 lbhcリソースのヘルスプローブへの応答がなくなるためか、テストページに到達できなくなりました。 注意点 ここまでご紹介した仮想IPの実装に関して、以下点にご注意ください。 WindowsとLinuxでクライアントからの接続フロー・設計・設定が異なるため、事前のマニュアル確認を行う。 ■Windows Azure 特有の設定について – LifeKeeper for Windows LIVE – 8.11.0 ■Linux Azure 上の LifeKeeper 特有の設定について – LifeKeeper for Linux LIVE – 9.9.1 Windowsでは、LifeKeeperで仮想IPを付与するNICとILBのバックエンドプールとして指定するNIC(IP)を別にする。 IPリソース作成時、対象サブネット(本検証では10.10.5.0/24)に対するルーティングの競合を避けるため、 「255.255.255.255」で設定する。 クライアントからクラスターへ向けた通信を、IP リソース(VIP)宛のパケット通信とする必要があるため、 [フローティングIP] は有効にする。 (アクティブノードからの応答も仮想 IP から送信される) ホスト名に小文字が含まれている場合、LifeKeeper で不具合が発生する恐れがあるため、ホスト名は大文字で作成する。 ⇒ 当初ホスト名に小文字を含めてLifeKepperを構築していたところ、LBHCリソースの作成でエラー(No140321)が発生。 ホスト名を全て大文字にすることで事象解消。 OSの設定漏れに注意。 Azure固有のOS設定が必要のため、以下の対応漏れに注意する。 ■Windows OS の設定 – LifeKeeper for Windows LIVE – 8.11.0 ■Linux OSの設定 – LifeKeeper for Linux LIVE – 9.9.1 さいごに 今回はAzureにおいて、LifeKeeperとILBを活用して仮想IPを機能させる方法をご紹介しました。 本記事を通じて、Azureでも仮想IPを機能させることができ、障害時にもクライアントが意識することなくシステムを継続利用できることをご理解いただけましたら幸いです! 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK Lifekeeper公式サイトまで
生成AIを活用した開発は急速に広がっています。しかし、いざ自分で取り組もうとすると「思った以上にハードルが高いのでは…」と感じたことはないでしょうか。 その背景には、 どこまでが自動化され、どこからが人間の役割なのかが直感的に分かりにくい という課題があります。その結果、「アプリを作るには結局どのくらいの知識が必要なのか」が見えづらく、最初の一歩が重くなってしまうのです。 誰もが試したいはずなのに…生成AIアプリ開発が“腰が重くなる”理由 生成AIアプリケーション開発に関連する知識領域 以下に、生成AIを活用したアプリケーション開発に関連する主な知識領域を独断と偏見で整理しました。 関連する知識ドメイン 内容 具体例 生成AI開発の専門用語と概念 開発現場では特有の用語や概念が飛び交い、それを理解する必要がある Claude Code、Gemini CLI、RAG、プロンプトエンジニアリング、MCP プログラミング AIが生成したコードを扱うためには、基礎的なプログラミング素養が欠かせない 言語文法、アルゴリズム、ソフトウェア設計手法(構造化、OOP、関数型)、エラー処理、DB連携、主要フレームワーク(Rails、Reactなど) クラウドインフラ 実際にアプリを公開するには、クラウド環境を含めたシステム全体を理解する必要がある アプリ実行形式(Webアプリ、スマホアプリ、API)、データベース設計、ネットワーク/クラウド基盤、UI/UX設計 運用・非機能要件 他者に安心して使ってもらえる品質を維持するには、テストや運用設計が必須 各種テスト手法、CI/CD、各種非機能要件の確保(セキュリティ、性能など) これらをすべて学びきってからでないとアプリが作れない――そんな風に考えると、確かに厳しいですよね。 “第一歩の軽さ”をもたらすFirebase Studio こうして見ると、生成AI開発には多くの知識が関わっていて、最初の一歩が重く感じられます。 でも、すべてを理解してから始める必要はありません。本エントリでは、 Firebase Studio を使って、環境構築や複雑な設定を最小限に、アイデアをすぐに形にし、アプリケーションとしてデプロイしていきます。 今回は、結婚式やパーティー会場で使える 写真共有アプリケーション を作っていきます。 もちろん、Firebase Studioを使えばもっと高機能なアプリケーションも作れますが、ここでは説明を分かりやすくするため、あえてシンプルな構成にしています。 このアプリは、 PythonやJavaScriptのプログラミングスキルがなくても構築でき、必要に応じて拡張していくことも可能 です。 興味が湧いてきましたか? では、さっそく作り方を見ていきましょう。 Webページとしてはちょっと縦長ですが、作業はほぼ一本道で進みます。 Step.1 まず、アプリケーションから作る 最初に行うのは、細かいプログラミングではなく 動くアプリケーションを用意すること です。 Firebase Studio ( https://studio.firebase.google.com/ ) にアクセスします。 初回はこのようなメッセージが表示されるので terms and conditions を受け入れて次の画面に行きます。 Firebase Studioの画面が表示されます。 (沢山アプリを作っているのでアプリ名などを加工して見えなくしています) 画面のように左ウィンドウにプロンプトを入力し、「Prototype with AI」ボタンを押しましょう。 入力したプロンプトは以下の通りです。 以下の機能を持つ、パーティー用のアルバムWEBアプリを作成してください。 写真を登録、削除する機能 複数の写真を一覧できるサムネイル機能 個々の写真を拡大して表示する機能 複数の写真を自動で切り替えるスライドショー機能 UIは、お祝いの場にふさわしい、明るくエレガントなデザイン リコメンド系の機能は不要 Firebase Studioはすぐにアプリケーションの構築プランを用意してくれます。 「Prototype this App」ボタンを押すと、すぐにAIがアプリケーションを開発し始めます。 わずか13秒後にアプリケーションが動き始めます。早い! 左側のウィンドウにアプリケーションが表示されるので、すぐに動かして動作検証ができます。 画像アップロードももちろん成功。画像の拡大やスライドショーだってできます。 アプリケーションが出来上がってしまいました。 ただし、このアップロードしたデータはまだどこにも保存されていないため、画面を再表示すると消えてしまいます。データをクラウド上のどこかに永続的に保存する必要があります。 そこで次のステップでは、 Firebaseプロジェクトの各種設定 を行います。具体的には、データを保存するための Firestore と Storage の設定、そしてアプリを外部に公開するための Firebase App Hosting の有効化とデプロイ手順について扱っていきます。 Step.2 アプリを動かすFirebaseを設定する アプリケーションを Firebase App Hosting にデプロイして公開します。 Step.2-1 Storageの設定 やりたい事は言葉(プロンプト)にしてAIに伝える、というのが基本です。 FirebaseプロジェクトをAI側で設定してくれました。 しかし、まだこの段階ではエラーが出ます。 エラーを渡してみます。 この後、Storageの権限設定を開始します。 Firebaseコンソール( https://console.firebase.google.com/ )の話が出てきましたので、アクセスします。 今回作ったアプリケーションが表示されているのでアクセスします。 左側の「構築」→「Storage」を選択するとStorageの画面が表示されます。 「プロジェクトをアップグレード」という文に、課金圧を感じますが課金の手続きをしましょう。課金プラン(Blazeプラン)については後述します。手順の詳細は省きますが、クレジットカードでの設定が便利です。 こんな感じで予算額と、それを超えた場合のメール通知も設定できます。仲間内で使う分には3000円、行かないと思いますが・・・。 Blazeプランの設定が終わったので、「使ってみる」を選択します。 保存先のロケーションにはこだわりが無いので、ここは「US-CENTRAL1」で セキュリティルールはデフォルトで提示されたもの(本番環境モード)でよいです。 おそらく後からAIに修正案を出してもらう可能性が高いです。もし、AIに修正案を提示してもらわなくても済んでしまった場合に備えて、厳しめに設定しておくことを推奨します。 この後、AIから修正を依頼された場合はFirebaseコンソールの「Storage」から、画面右側の「ルール」タブを選択しましょう。こちらからルールを編集できます(アプリの情報を開示しないため、白く塗りつぶしています)。 Storageの設定を完了すると、アプリケーションが動くはずですが、もしかするとコーディングエラーが発生しているかもしれません。 エラーが発生した時は、以下のような表示が出ることが多いので「Fix Error」しましょう。ボタンが出ないときは、エラー内容を入力欄に張り付ければ対応してもらえます。 これで動くようになりました。 AIは決定論的に毎回同じ挙動をするわけではないので、違う流れで進むかもしれませんが、おおむねこのような流れで作業を行うとアプリケーションが完成します。 Storageの設定完了により、データがクラウド上に保存されるようになりました。 Step.2-2 Firebase App Hostingへのデプロイ あとは、「Firebase App Hosting」を使ってアプリケーションをクラウド上にデプロイするだけです。ゴールはもうすぐ。画面の右上を見てください。「Publish」というボタンが見えるはずです。 ここまでの設定ができていれば、このボタンを押して表示される命令をすべて対応すればデプロイが完了します。 「Set up services」を押せば「Firebase App Hosting」にアプリケーションがデプロイされ、晴れてWebアプリケーションとして動作することになります。お疲れさまでした! まとめ 取り扱った内容 ここまでで、Firebase Studioを使って 写真共有アプリケーションを作成 し、さらに Firebaseプロジェクトの設定 を通じて以下を整えました。 Firebase Studio を利用して アプリケーションを構築 Firebase Storage を利用して 実際の画像ファイルをクラウドに保存 Firebase App Hosting を利用して Webサイトとしてアプリを公開 今後について 今回暑かったのは「パーティー用の写真共有アプリ」でした。つまり、共有範囲を限定でき、問題が発生した時の影響が小さいことが前提のアプリです。これを本格的に他の人が使えるアプリにするためには様々な考慮が必要です。 Firebase Studioでプロンプトベースの開発を進めていくうえで、知っておくべきこと、知っておいた方が良い事について、今後エントリを上げていきますので、よろしくお願いいたします。 伝えたい事 Firebase Studioで実際にアプリを作り始めてみると、次第に「 プロンプトの工夫が必要だ 」とか「 AIが生成したコードの不具合にどう対処するか 」といった課題に気づくはずです。 ただし、これらは事前に机上で考えすぎても答えが出にくいものです。 一度手を動かして作ってみることで初めて分かることが多い 、というのが正直な感想です。 その点、Firebase Studioは入口の敷居がとても低く、誰でもすぐに「作ってから学ぶ」というサイクルに入ることができます。 せっかくこれほど便利で強力な環境が整っているのですから、ぜひまずは一度、手元でアプリを作ってみませんか
CloudWatchで監視を実装している環境に対して、夜間バッチ処理中はアラームを抑制することで、不要な通知を避けたいということはよくあることかと思います。 本記事では、CloudWatchのMetric Mathを活用して、特定の時間帯だけアラームを抑制する設定を行った実践例をご紹介します。 Metric Mathを採用した理由 まずはじめにCloudWatch監視における非監視設定の選択肢について考えました。 非監視時間に合わせてCloudWatchアラームを無効化/有効化する CloudWatch アラームとSNS トピックの間にLambda関数を仕込み、時間をチェックし非監視時間帯であれば通知を抑止するよう作りこむ MetricMath関数を使って、非監視時間帯のメトリクスを正常メトリクスとして上書きする 今回、非監視時間帯に本当に発生したアラートは、非監視時間帯明けに通知させたいという要件がありました。 CloudWatchではSNSやLambdaなど、アラートを検知した際に他サービスと連携することができますが、これはアラームの状態が遷移したことをトリガーにするため、非監視時間帯にアラート状態になったアラームは非監視時間帯が明けても通知されず、アラートに気づかないことがあるわけです。 監視明けのアラームの状態をチェックするにはまたLambda作りこみが必要となり、面倒くさい・・・。 MetricMath関数では、関数の通りにメトリクスの値を上書きできるイメージのため、非監視時間帯はわざと正常な値で上書き、非監視時間帯が明けたら実際の値を取得します。 非監視時間帯が明けたタイミングでアラーム状態に遷移してくれるので、楽に実装できそうとなり、MetricMath関数を使ってみることにしました。 Metric Mathとは? CloudWatchのメトリクス(CPU使用率、ディスクI/O、リクエスト数など)に対して、加算・減算・乗算・除算・統計関数などを使って計算を行うことができます。 例えば、 複数のEC2インスタンスのCPU使用率の平均を出す リクエスト数とエラー数からエラー率を計算する カスタムメトリクスを組み合わせて複雑な条件でアラームを設定する みたいなことができます。 よく使われる関数 関数 説明 SUM([m1, m2]) メトリクスm1とm2の合計 AVG([m1, m2]) 平均値 MAX([m1, m2]) 最大値 MIN([m1, m2]) 最小値 RATE(m1) 単位時間あたりの変化率(カウンター系メトリクスに便利) IF(condition, value_if_true, value_if_false) 条件分岐 CloudWatch メトリクスでの数式の使用 – Amazon CloudWatch やってみた 今回は特定の時間帯だけアラームを抑制したいので、タイムスタンプに基づいて値を返してくれる関数を利用します。 関数 説明 MINUTE 元の時系列の各タイムスタンプで UTC 分を表す、非スパース時系列 (0~59 の整数) を返します。 HOUR 元の時系列の各タイムスタンプで UTC 時間を表す、非スパース時系列 (0~23 の整数) を返します。 DAY 元の時系列の各タイムスタンプで UTC 曜日を表す、非スパース時系列 (1~7の整数) を返します。1 は月曜日を、7 は日曜日を表します。 DATE 元の時系列の各タイムスタンプで UTC 日付を表す非スパース時系列 (1~31の整数) を返します。 今回は毎晩2:00~4:00の間アラームを抑制してみます。 タイムスタンプは UTC 基準のため、UTC17:00~19:00を関数で表現します。 IF(AND(HOUR(m1) >= 17, HOUR(m1) < 19), 10, m1) HOUR(m1) はメトリクス m1 のタイムスタンプの「時」を取得(UTC) 13 <= HOUR < 17 の時間帯(17:00〜18:59)に該当する場合、値を 10 に上書き それ以外の時間帯は元のメトリクス m1 の値を使用 MetricMath関数を使ったメトリクスとアラームを作成 対象のメトリクスを選択し「数式を追加」をクリックします。 [すべての関数]-[IF]を選択。 追加されたメトリクスの[詳細]欄の編集マークをクリックし、設定したい関数を入力し、「適用」をクリック IDやラベルは任意で設定してください。 作成したメトリクスの鈴マークをクリック お好みでアラーム設定 作成したメトリクスを確認してみます。 このメトリクスはTomcatのプロセス数を取得しており、本来の値は1が記録されています。 グラフから2:00~3:59は本来のメトリクス値でなく、一律10という値で記録されていることがわかります。 監視設定ではメトリクスが0になったらアラート状態になるよう設定しましたので、2:00~3:59の間はアラート状態にはなりません。 2:00~3:59にアラート状態になった場合も、2:00~3:59ではなく非監視時間帯が明けた4時に通知されました。 ※非監視時間内に正常に戻った場合は通知されません。 さいごに Lambda等その他のサービスを使うことなく、非監視設定できたのは大変ありがたいです。 Lambdaの管理も必要なく運用負担も軽減できる点も嬉しいですね。
こんにちは、SCSKの坂木です。 本記事では、 Zabbixサーバのインストールを自動化するシェルスクリプトを紹介 します! 検証環境 今回、検証に使用した環境は以下の通りです。 コンポーネント バージョン/種類 備考 OS Amazon Linux 2023 RHEL系のディストリビューション データベース MySQL Community Server Zabbixで広く利用されているデータベース Zabbix Zabbix7.0 LTS 2025/08時点での最新の長期サポート版 この構成に基づき、本ブログで公開するスクリプトは 「RHEL系OS + MySQL」の環境に、Zabbix 7.0 LTSをインストール するものとなっています。 もし異なるOS(Ubuntuなど)やデータベース(PostgreSQLなど)をご希望の場合は、一部カスタマイズが必要となりますので、あらかじめご了承ください。 前提条件 MySQLサーバが起動していること 本スクリプトはZabbixサーバのコンポーネントをインストールし、DBに接続する設定を行いますが、MySQLサーバ自体のインストールや起動は行いません。あらかじめMySQLが利用可能な状態にしておいてください。 OSがZabbixサーバのバージョンに対応していること Zabbixサーバはバージョンごとに公式にサポートされるOSが定められています。対応しているOSのバージョンは こちら を確認してください。 RHEL系のOSであること このスクリプトは、パッケージ管理にdnfコマンドを利用するなど、RHEL系のOSに特化して作成されています。 インストールスクリプト スクリプトはこちらになります。 #!/bin/bash set -e # 1. MySQLのrootユーザーのパスワード MYSQL_ROOT_PASS='<MySQLのrootユーザーのパスワードを入力してください>' # 2. Zabbixがデータベース接続用に使う新しいパスワード ZABBIX_DB_PASS='<MySQLのzabbixユーザのパスワードを入力してください>' echo "--- Zabbixリポジトリの追加とパッケージのインストールを開始します ---" rpm -Uvh https://repo.zabbix.com/zabbix/7.0/amazonlinux/2023/x86_ 64/zabbix-release-latest-7.0.amzn2023.noarch.rpm dnf clean all dnf install -y zabbix-server-mysql zabbix-web-mysql zabbix-apache-conf zabbix-sql-scripts zabbix-agent echo "--- Zabbix用データベースとユーザーを作成します ---" mysql -u root -p"${MYSQL_ROOT_PASS}" <<EOF CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; CREATE USER 'zabbix'@'localhost' IDENTIFIED BY '${ZABBIX_DB_PASS}'; GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost'; SET GLOBAL log_bin_trust_function_creators = 1; EOF echo "--- Zabbix初期スキーマとデータをインポートします ---" zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql --default-character-set=utf8mb4 -uzabbix -p"${ZABBIX_DB_PASS}" zabbix echo "--- log_bin_trust_function_creators の設定を元に戻します ---" mysql -u root -p"${MYSQL_ROOT_PASS}" <<EOF SET GLOBAL log_bin_trust_function_creators = 0; EOF echo "--- Zabbixサーバーの設定ファイル(/etc/zabbix/zabbix_server.conf)を編集します ---" sed -i "s/^# DBPassword=/DBPassword=${ZABBIX_DB_PASS}/" /etc/zabbix/zabbix_server.conf echo "--- 関連サービスを再起動し、自動起動を有効化します ---" systemctl restart zabbix-server zabbix-agent httpd php-fpm systemctl enable zabbix-server zabbix-agent httpd php-fpm echo "--- Zabbixのセットアップが正常に完了しました ---" 適当なディレクトリに配置してスクリプトを実行してください。 [root@ip-10-0-30-48 work]# ll total 4 -rwxr-xr-x. 1 root root 1769 Aug 28 14:15 zabbixautoinstall.sh [root@ip-10-0-30-48 work]# ./zabbixautoinstall.sh 実行確認 スクリプト実行後、問題なくzabbixが起動しているか以下のポイントを確認します。 systemctl statusコマンドでzabbixサーバ、zabbixエージェントが起動していること # systemctl status zabbix-server ● zabbix-server.service - Zabbix Server Loaded: loaded (/usr/lib/systemd/system/zabbix-server.service; enabled; preset: disabled) Active: active (running) since Thu 2025-08-28 14:17:48 UTC; 1min 25s ago # systemctl status zabbix-agent ● zabbix-agent.service - Zabbix Agent Loaded: loaded (/usr/lib/systemd/system/zabbix-agent.service; enabled; preset: disabled) Active: active (running) since Thu 2025-08-28 14:17:48 UTC; 1min 31s ago zabbixのwebインタフェースにアクセスできること まとめ 本記事では、スクリプトを実行するだけでZabbix 7.0を自動インストールする手順をご紹介しました。なお、本記事で提供するスクリプトは、以下の環境を前提としています。 OS: RHEL系 (Rocky Linux, AlmaLinux など) データベース: MySQL Zabbixバージョン: 7.0 もし上記以外の環境(例: Ubuntu, PostgreSQL)でZabbixを構築されたい場合は、本スクリプトは対応しておりませんのでご注意ください。その場合は、Zabbix公式ドキュメントを参考に手動でインストールをお試しいただくか、今後の記事で別の環境向けのスクリプトを公開するまでお待ちいただけますと幸いです。
こんにちは! Catoクラウド 技術担当の中川です。 この記事はCatoクラウドのPoCの進め方をご説明する記事になります。 SCSKはこれまで多くのお客様へPoCのご支援をさせていただきました。 この記事ではそれらの実績をもとに、PoC前に準備しておくべきことから、PoCのよくある検証項目、困ったときの対処方法までご紹介しています。 また検証項目のご説明は、TechHarmonyで私たちが作成してきたブログを引用しリンク集のような記載にしています。 気になる機能は随時各リンクへアクセスください。 Step0 PoCを始める前に PoC概要 PoCの概要としては、以下のようになっています。期間やライセンス数にご注意いただければと思います。 期間:30日 モバイルユーザ:5ライセンス ※1ライセンスにつき端末3台まで利用可能 Cato Socket X1500:1台 ※原則1台ですが、台数調整は可能 Siteの帯域:上限なし ※接続回線に合わせて設定 セキュリティオプション:すべて利用可能 PoC構成 PoCのよくある構成例 CatoクラウドのPoC構成について CatoクラウドでのPoC実施において、本番通信に影響を与えずにテストを行うためのネットワーク構成をご紹介します。よくあるネットワーク構成を例に、Cato Socketの設置位置やルーティング設定を解説します。 blog.usize-tech.com 2025.07.07 既存のNW環境にSocketをどのような構成で検証したらいいのか、上記ブログで詳しくご紹介しています。 PoC期間は30日間しかなく、普段の業務と併行して検証いただくケースも少なくないと思います。 PoCを始める前に、構成や検証予定の項目を事前によく決めておくことが重要です。 Socketのスペースを確保 構成が決まったら、拠点でSocketの設置スペースを確保します。 Socketのサイズは次の通り2パターンあります。どちらの貸し出しになるかは選択いただけませんので、ご容赦ください。 W165mm x D105mm x H43mm (X1500) W180mm x D130mm x H30mm (X1500B) サイズご参考写真(上がCato Socket X1500、下はサイズ比較用の Cisco 891FJ) 検証用端末を準備 検証用端末(PCやスマートフォン)の準備もお忘れなくお願いします。 Socket配下に接続する端末と、Catoクライアントをインストールして拠点外から接続する端末が必要です。 ※両方同じ端末でも問題ございません Catoクライアントは、他のVPN・リモートアクセスソフトと競合し、正常に動作しない場合がございます。 Catoクライアントをインストールする端末では、事前にアンインストールをお願いします。 また、拠点外からのインターネット接続環境(自宅回線、モバイルルータ、テザリング等)も準備ください。 Step1 いざCatoクラウドへ接続 Step0の前準備が終わったら、いよいよPoC開始です! Socketの接続とモバイル接続 まずはCatoクラウドへ接続するところからです。 はじめの一歩 を参考に、Socketを使ったSite接続とモバイルユーザの接続から行いましょう。 Site接続とモバイル接続 Catoクラウド はじめの一歩 Catoクラウドのテナント開設後、テストユーザ・テスト拠点をCatoクラウドへ接続するまでの流れを紹介します。 blog.usize-tech.com 2023.08.18 vSocketで接続 Site接続でvSocketを利用される場合には、FAQサイトへご契約社様のアカウントでログインいただき、下記のFAQにて提供している手順書をご参考ください。 なお、AWS vSocketの構築方法は近日中にTechHarmonyでも公開予定です! vSocketの構築 よくあるご質問 | SCSK株式会社 よくあるご質問 | SCSK株式会社 cato-scsk.dga.jp よくあるご質問 | SCSK株式会社 よくあるご質問 | SCSK株式会社 cato-scsk.dga.jp モバイルユーザのプロビジョニング モバイルユーザを手動ではなく、プロビジョニングで作成してみたい場合には下記のブログをご参考ください。 Entra IDとの連携 【Catoクラウド】SCIMプロビジョニングでユーザを作成・管理する SCIMプロビジョニングによるユーザ作成・管理について、注意点も含めて紹介いたします。 blog.usize-tech.com 2025.04.03 LDAP連携 【Catoクラウド】ADからユーザをプロビジョニングしてみた CatoへADからLDAP連携でユーザをプロビジョニングする際の手順と注意点をまとめております。 blog.usize-tech.com 2024.12.14 CMAの見方 Catoの管理コンソールをCMAと呼びますが、CMAの見方・使い方を解説した記事もありますので不明点があればこちらもご参考ください。 CMA(Catoの管理コンソール)解説 【入門編】Catoの管理画面 Cato Management Application(CMA)を解説! Catoクラウドの管理画面 Cato Management Application (CMA) を実際の画面を交えて見方と主に使用する項目について紹介していきます。 blog.usize-tech.com 2023.09.29 STEP2 ネットワーク設定とログの確認 ネットワーク設定 各リソースへ接続テストされる際に、必要となる可能性のある設定が2つあります。 社内ドメインへのアクセス 1つは社内ドメインにあるリソースです。 CatoではデフォルトのDNSが設定されており、社内ドメインのサイトを名前解決するには追加で設定が必要です。 PoC時に社内ドメインのサイトへ検証される場合は、下記ブログのDNS Forwardingの項でご紹介している方法で追加ください。 社内ドメイン接続用のDNS設定 CatoクラウドのDNS設定について CatoクラウドのDNS設定について網羅的に解説します。 blog.usize-tech.com 2024.08.12 固定IP制御しているSaaSへの接続 もう1つは、送信元IPを固定してアクセスする必要があるSaaSなどです。 Catoでは、グローバルの固定IPをお客様テナントで取得できます。固定IP取得の仕方、ルーティングの仕方などは以下ブログをご参考ください。 固定IPで制御しているSaaSへの接続 CatoクラウドにおけるEgress IP(送信元IP、出口IP)について CatoクラウドにおけるEgress IPについて解説します。 blog.usize-tech.com 2023.08.22 ログの確認 各リソースへアクセスできるようになりましたら、CMAでログを確認してみましょう。 Catoクラウド導入後の日々の運用は、イベントログから調査することになります。ぜひPoC時に使い慣れておくことをオススメします。 ログの確認 Catoクラウド Eventsの確認方法 CatoクラウドのEvents画面の見方、ログの絞り込み方について解説します。 blog.usize-tech.com 2023.08.22 【Catoクラウド】イベントログ(Events)確認方法・2025年版 Catoクラウドでのイベントログ(Events)の確認・調査方法を解説する記事です。2025年5月までに追加された、便利な機能更新も含めて紹介してまいります。 blog.usize-tech.com 2025.06.16 STEP3 セキュリティ機能を使ってみる テストしたいリソースへ接続確認できましたら、セキュリティ機能を使ってみましょう。 PoCでは、本番導入時には有償のセキュリティオプションがすべて利用できます。検証しておかない手はありませんね。 PoC時点では使う予定がなくても、本番導入後に追々、セキュリティ対策が必要になることも多くございます。 是非この機会にお試しください! セキュリティ機能 セキュリティ機能ごとにブログのご用意があります。各ブログをご参考の上、検証いただければと思います。 Firewall CatoにはInternet FW、WAN FW、LAN FWの3種類の機能が用意されています CatoクラウドのFirewall機能について CatoクラウドのFirewall機能について解説いたします。 blog.usize-tech.com 2023.09.28 Threat Prevention Threat Preventionには、「Anti-Malware」「次世代Anti-Malware(NGAM)」「IPS」の3機能があります 【Catoクラウド】Anti-Malware・IPSの操作方法と挙動について Catoクラウドのセキュリティ機能のうち、Threat Preventionオプションにて提供されるAnti-MalwareとIPSについて詳しく紹介いたします。 blog.usize-tech.com 2025.08.08 CASB クラウドアプリケーションに対する操作の可視化・制御をする機能です CatoクラウドのCASBについて Catoクラウドのセキュリティオプション CASB について解説します。 blog.usize-tech.com 2023.09.12 CASBの制御って何をしたらいいの? ~ルールの設定例 CASBでの一般的なクラウドサービス制御ルール例をご紹介します。 blog.usize-tech.com 2025.01.23 DLP CASBをベースとして、アプリケーション制御に追加するデータおよびコンテンツの検査を行う機能です CatoクラウドのDLPについて Catoクラウドの情報漏洩対策にあたる「DLP」について紹介していきます! blog.usize-tech.com 2023.10.06 DLPって具体的に何ができるの? ~ルールの設定例 データ持ち出し対策のひとつである、Data Loss Prevention(DLP)の設定例をご紹介します。 blog.usize-tech.com 2025.03.10 デバイス制御 モバイルユーザに対するデバイスの制御です。 すべての機能が無償でご利用でき、特にAlways-Onは多くのお客様にご利用いただいている機能です。 Always-On 端末が常時Catoクラウドを必ず経由するようにする機能です CatoクラウドのAlways-Onを試してみた Catoクラウドで「Always-On」を試してみました。設定方法~動作検証までやってます。 blog.usize-tech.com 2023.08.28 Cato クラウド Always-On の新機能を徹底解説! ~2023.11のアップデートについて~ 2023年11月にアナウンスされた Cate クライアント Always-On のアップデート情報です。 blog.usize-tech.com 2023.12.13 デバイス証明書認証 指定した電子証明書がインストールされている端末からのみ、Catoへの接続を許可する機能です Catoクラウドでのデバイス証明書認証について Catoクラウドでのデバイス証明書認証の設定方法、エラー事例をご紹介します。 blog.usize-tech.com 2024.01.11 デバイスポスチャー ウイルス対策ソフトやパッチ管理ソフトなど、特定のセキュリティソフトがインストールされている端末からのみ、Catoへの接続を許可する機能です CatoクラウドでDevice Postureを利用したい Device Postureの簡単な設定例と動作検証結果をご紹介します。 blog.usize-tech.com 2024.05.17 困ったときは 上記の通り、TechHarmonyではたくさんのCato機能をご紹介していますが、解決しない事象が発生することもあると思います。 そんな時は、SCSK、Catoそれぞれが提供している以下のサポートをぜひご活用ください。 SCSKがご提供するサポート SCSKでは以下のサポートをご提供しています。コンテンツの拡充、機能拡張を随時行っておりますのでぜひご活用ください! FAQサイト よくあるご質問 | SCSK株式会社 よくあるご質問 | SCSK株式会社 cato-scsk.dga.jp これまでのご支援実績をもとに様々な問い合わせにお答えしています。 SCSKでPoCをご契約いただきますと、ご契約者様用のアカウントを発行させていただきます。ご契約者様用のFAQでは、詳しい仕様の確認や手順書のダウンロードが可能です。 AIチャットボット 「SCSK Cato クラウド AI チャットボット」をリリースしました SCSKが開発した「Catoクラウド AIチャットボット」の機能・利便性・導入効果をご紹介します。 blog.usize-tech.com 2025.02.14 CatoのKnowledgeBaseおよび、FAQサイト、TechHarmonyを情報源として、チャット形式でお問い合わせに回答します。 Youtube動画リンク集 よくあるご質問 | SCSK株式会社 よくあるご質問 | SCSK株式会社 cato-scsk.dga.jp トラブル事例やセキュリティ機能を動画形式でご紹介しています。 特に、よくいただくお問い合わせを以下にピックアップしてみました。 最初につまづきやすい事例をご説明していますので、お困りの際はまずはこれらのサイトからご確認いただければと思います。 Catoクラウドで接続したときのみ、特定のWebサイトが表示できない 特定Webサイトへのアクセスができない | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Catoクラウド経由で、特定のWebサイトへアクセスができないことがあります。Webブラウザによりエラー内容は異なりますが「403 Forbidden」「このページは動作しておりません」「アクセスしよ... cato-scsk.dga.jp Catoクラウドで接続したときのみ、特定のWebサイトで証明書エラーが表示される TLS Inspection 除外について | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK TLS Inspection機能をOnにすると、Catoクラウドで暗号化通信(HTTPS)を復号化して各種セキュリティチェックを行い、Catoの証明書を用いて暗号化を行うため、クライアントには、Catoのルート... cato-scsk.dga.jp Catoクライアントが繋がらない Catoクラウド トラブルシュート ~Catoクライアントが繋がらないお悩みの方へ~ Catoクラウドをご利用いただいてるお客様から、よくいただくご質問に「Catoクライアントが繋がらないです」といったお問い合わせを頂きます。対処法や問題の切り分け方をご紹介いたします。 blog.usize-tech.com 2023.12.15 Catoが提供するサポート Cato社が提供しているサポートは以下の2つがあります。 Cato社へお客様から直接お問い合わせすることも可能ですが、英語のみでの問い合わせになることにご注意ください。 また、弊社のAIチャットボットとは別に、Cato社提供のAI機能がございます。 Cato社へのチケットによる問い合わせ ※問い合わせ言語は英語のみ Cato Networksへの問い合わせ、調査依頼方法について | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Catoクラウド利用時にトラブル等が発生した際は、Cato Networks社のサポートへ直接問い合わせや調査を依頼することが可能です。Cato社のサポートとのやり取りは、すべて英語となります。日本... cato-scsk.dga.jp CatoのAIアシスタント ※情報源はKnowledgeBaseのみ 【Catoクラウド】新機能「AIアシスタント」がリリース Catoクラウドより、2025年1月6日のアップデートにてAIアシスタントがリリースされました。AIアシスタントの実際の使用感や回答精度などについて記載しています。 blog.usize-tech.com 2025.01.30 最後に いかがでしたでしょうか。 ご覧いただいた通り、Catoでは様々な機能がありますので、PoCでは特に気になる機能からピックアップして検証いただくことをオススメします。 また、SCSKでのPoCご支援では、これまでの多くのご支援実績に基づいたサポートと、FAQサイトやAIチャットボットなどをご提供させていただきますのでご安心してご依頼いただければと思います!
こんにちは、SCSKの伊藤です。 保守業務とは切っても切れないトラブルシュート。 本記事では、LifeKeeperでのイベント監視および参照方法について、設定方法も含めてご紹介します。 LifeKeeperイベント監視の種類について イベント監視の種類について、LinuxとWindowsで下記の方法があります。 【Linux】 ログ SNMPトラップ メール 【Windows】 ログ SNMPトラップ LifeKeeperログの確認方法 LifeKeeperのログについては、下記の方法で参照することができます。 [Linux]CLIコマンドでログファイル「/var/log/lifekeeper.log」を表示する。 [Windows]WindowsのイベントビューアからApplicationおよびシステムを表示する。 [Windows/Linux共通]LifeKeeper GUIまたはLifeKeeper Web Management Consoleから、リソースツリーのサーバ名を右クリックし、表示されたメニューから[View Log](日本語の場合は[ログの表示])をクリック LifeKeeperログの見方 LifeKeeperのログは、以下のような形式で出力されます。 LifeKeeper for Linuxのログ Aug 25 13:25:19 rhel01 quickCheck[4974]: ERROR :qsp: quickCheck : QSP-snmptrapd : 134607 : systemctl command has failed for “QSP-snmptrapd” ERROR : 重大度 quickCheck : 実行処理 QSP-snmptrapd : リソース名 134607 : コード systemctl~ : メッセージ LifeKeeper for Windowsのログ [08/29/2025 11:25:36] EventType: Error, Source: LifeKeeper, Category: General Process: lkresfail.exe(1168) * ERROR * (No. 1620 ) Local recovery of resource IP-192.168.10.55 failed. ERROR : 重大度 1620 : コード Local Recovery~ : メッセージ 色を付けた部分の意味は、それぞれ下記の通り。 重大度 EMERG/FATAL LifeKeeper自体の動作に影響を及ぼす可能性のある内容 ERROR LifeKeeperのサービスやリソースに影響を与える障害 WARN LifeKeeperのサービスやリソースに対し、直ちに異常を示すものではない注意や警告 NOTIFY LifeKeeper自体やリソース等の状態が遷移したこと示す通知 INFO LifeKeeperに関する情報のメッセージ 実行処理(Linuxのみ) restore リソースの起動処理 remove リソースの停止処理 quickCheck リソースの監視処理 deepCheck リソースの詳細監視処理 recover リソースの回復処理 <空白> 上記のいずれにも該当しないLifeKeeperの内部処理など リソース名(Linuxのみ) アラート元のリソース名が表示されます。 コード・メッセージ 各コードおよびメッセージは、SIOSマニュアルサイトのメッセージカタログに記載されておりますが、記載がないメッセージの詳細を確認したい場合はSIOSへの問い合わせが必要になります。 LifeKeeperメッセージカタログ(Linux) https://docs.us.sios.com/spslinux/9.9.1/ja/topic/combined-message-catalog LifeKeeperメッセージカタログ(Windows) https://docs.us.sios.com/sps/8.11.0/ja/topic/combined-message-catalog DataKeeperメッセージカタログ(Windows) https://docs.us.sios.com/sps/8.11.0/ja/topic/message-catalogs Linux版はv9.9.1、Windows版はv8.11.0のリンクとなります。 Linux版は、LifeKeeperメッセージカタログにDataKeeperのメッセージも含まれます。 SNMPトラップによるイベント通知 LifeKeeperは、SNMPトラップでイベント通知することができます。 LifeKeeperのSNMPトラップはOSの機能を使用しているため、Windowsの場合は『SNMP サービス』の機能を追加、Linuxの場合は「net-snmp-utils」(RHEL5以降)または「net-snmp」(SLES11以降)のパッケージ導入を事前に完了しておく必要があります。 WindowsにSNMPサービスをインストールせずLifeKeeperをインストールした場合、LifeKeeperのSNMPトラップ設定がスキップされてLifeKeeperでSNMPトラップで利用できなくなりますので、LifeKeeperの再インストール処理を実行する必要があります。 LifeKeeper for LinuxのSNMPトラップ設定方法 CLIにて「/opt/LifeKeeper/bin/lk_configsnmp <IPアドレスorホスト名> –query」コマンドを実行 CLIにて「/usr/share/snmp/snmp.conf」ファイルに”defCommunity <コミュニティ名>”の記載を追加 (snmp.confファイルが存在しない場合は作成) LifeKeeper for WindowsのSNMPトラップ設定方法 1. Windowsツールのサービスから『LifeKeeper External Interfaces』 を起動(デフォルトは自動起動) 2. Windowsツールのサービスから『SNMP サービス』のプロパティを開き、「トラップ」タブより”コミュニティ名”と”トラップ送信先”を追加 3. Windowsツールのサービスから『SNMP サービス』を再起動 SNMPトラップ通知の見方 LifeKeeperのSNMPトラップは、以下のような形式で出力されます。 LifeKeeper for LinuxのSNMPトラップ Aug 27 16:22:18 snmpserver01 snmptrapd[2343]: 2025-08-27 16:22:18 lkserver02 [UDP: [192.168.10.102]:33294->[192.168.10.100]:162]:#012DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (6370) 0:01:03.70#011SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.7359.1.0. 100 #011SNMPv2-SMI::enterprises.7359.1.1 = STRING: “LifeKeeper Startup Complete” lkserver02 : SNMPトラップ送信元サーバ 100 : トラップコード “LifeKeeper~ : メッセージ LifeKeeper for WindowsのSNMPトラップ Aug 27 15:42:47 snmpserver01 snmptrapd[2343]: 2025-08-27 15:42:47 192.168.10.99 (via UDP: [192.168.10.99]:51372->[192.168.10.100]:162) TRAP, SNMP v1, community public#012#011SNMPv2-SMI::enterprises.7359.1 Enterprise Specific Trap ( 111 ) Uptime: 0:06:28.38#012#011SNMPv2-SMI::enterprises.7359.1.1.0 = STRING: “LifeKeeper Manual Switchover Complete” #011SNMPv2-SMI::enterprises.7359.1.3 = STRING: “LKSERVER01″#011SNMPv2-SMI::enterprises.7359.1.3 = Hex-STRING: 32 30 32 35 94 4E 20 38 8C 8E 20 32 37 93 FA 20 #01290 85 97 6A 93 FA 20 31 35 3A 34 32 3A 34 38 20 #01220 20 20 #011SNMPv2-SMI::enterprises.7359.1.3 = STRING: “ IP-192.168.10.111 “ 192.168.10.99 : SNMPトラップ送信元サーバ 100 : トラップコード “LifeKeeper~ : メッセージ IP-192.168.10.111 : リソース名 使用するSNMPクライアントおよびMIB導入状況によって、表示形式が若干異なる場合があります。 色を付けた部分の内、トラップコードおよびメッセージ以外の意味については「LifeKeeperログの見方」箇所を参照。 トラップコード・メッセージ 各トラップコードおよびメッセージは、SIOS技術情報サイトに一覧が記載されております。 SNMP トラップのメッセージが出力されるケース https://lkdkuserportal.sios.jp/hc/ja/articles/900004364383–Linux-Windows-SNMP 特定アラートのみをSNMPトラップ送信するような設定はありませんので、SNMPトラップの受信先で振り分けする必要がある点に注意してください。 メールによるイベント通知 LifeKeeperは、メールにてイベント通知することができます。 LifeKeeperのイベントメール通知機能は、mailxまたはs-nailパッケージのメールユーティリティを使用して通知を送信するため、事前にメールユーティリティの導入および設定が必要となります。 メールの設定については、その環境に合わせた設定が必要になります。 ・LifeKeeper for Linuxのイベントメール通知設定方法 CLIにて「/opt/LifeKeeper/bin/lk_confignotifyalias <送信先メールアドレス>」コマンドを実行 イベントメール通知の見方 LifeKeeperのイベントメール通知は、以下のような形式で出力されます。 LifeKeeper for Linuxのイベントメール通知 差出人 : 送信元サーバのメールアドレス(メールの設定により異なります) 件名 : メッセージ 内容 : メッセージ(件名と同じ) メッセージ 各メッセージは、SIOSマニュアルサイトに一覧が記載されております。 メールが生成される LifeKeeper のイベント https://docs.us.sios.com/spslinux/9.9.1/ja/topic/overview-of-lifekeeper-event-email-notification 一部のイベントのみ送信または除外するような設定はありませんので、メールを受信する環境にて振り分けおよび除外する必要がある点に注意してください。 さいごに 今回はLifeKeeperのイベント監視についてご紹介させていただきました。 メール通知に関しては、お客様から問い合わせをいただくことも多々ありますので、少しでも参考になれば幸いです。 詳しい内容をお知りになりたいかたは、以下のバナーからSCSKLifekeeper公式サイトまで
こんにちは。SCSK渡辺(大)です。 外を歩いていたら目が痒くなり、クシャミが出ました。 秋花粉の足音が聞こえた気がして震えています。 さっそく納品 500円で音声付きアニメーション動画は作れます。 ただし何かしらの妥協が必要だということが以下の成果物から感じていただけるかと思います。 アニメーション動画 キャラクターの造形が若干崩れ、音声は機械的な声になっています。 苦手な方は視聴をお控えください。 本当は30秒にしたかったのですが、キャラクターの造形が崩れてしまうものが多く、比較的綺麗に仕上がった動画を採用しました。 奇跡的に8~9秒あたりで音がハマっています。 「ワン!」の後の言葉は犬が話していると思ってください…。 document.createElement('video'); https://blog.usize-tech.com/contents/uploads/2025/08/anime.mp4 概要資料 6スライド目の構築手順フローは想像していたものと異なっているため、後半で補足します。 まずは感想 画像や動画、音声を直感的に作れるのは凄く楽しかったです。 AWS Elemental MediaConvertは正直存在を認知できていませんでした。便利なサービスですね。私のような一般人はどちらかというと日常生活で使う機会が多いのかと思います。 Amazon Nova Reelは発展途上という感じがしました。 現状だとファインチューニングが出来ないので、プロンプトが重要かと思います。 今回は奇跡的にキャラクターの造形が大きく崩れない動画が生成されましたが、本来は意図的に生成できないといけないと思います。他サービスと比較するとコストが高いので、慎重に使わないとですね。 Amazon PollyのエンジンにGenerative(生成AI)があるのですが、残念ながら日本語は非対応でした…。 Amazon Nova Sonicも日本語は非対応なので、Amazon PollyのGenerativeはAmazon Nova Sonicを使っているのかと思われます。 以下の記事にあるようにAmazon Nova Canvasはファインチューニングできるので、現在の環境下で想像通りのアニメーション動画を作成したい場合にはAmazon Nova Canvasだけでもファインチューニングしたほうが良い気がしました。 Amazon BedrockでWordPress記事のアイキャッチ画像を自動生成する Amazon Bedrockを用いて、WordPress記事のアイキャッチ画像を自動生成・付与する仕組みをつくってみました。 blog.usize-tech.com 2025.08.31 背景 もともと、業務とは別に、AWS上で何か子供向けのコンテンツを作りたいなとは考えており、「ゲーム」「絵本」「アニメ」が候補でした。 前々回、前回と2回連続で「ゲーム」に関する記事を書いてみたところ、前回の記事について同僚から「Amazon Nova SonicでBGMも作れるのかな?」というコメントをいただいたので、Aamzon Nova Sonicを調べてみました。 Aamzon Nova SonicのコンセプトからするとBGMを作成する用途ではなさそうでしたが、簡単に「声」を作成できるという点に興味を持ちました。 その後、Amazon Novaに関する勉強会に参加し、Amazon Nova Reelで6秒以上の動画(最大120秒)を作成できるようになったことを知りました。 最後に、最近ついにKiroと友達になれたことで、今回の記事執筆に至りました。 新しい友達のKiro まだ数日触っただけですが、個人的に気に入っていることは以下です。 軽い ログが分かりやすい MCPの実行結果を畳んで表示してくれる AWSCLIの実行状況がターミナルで見れる 本当はKiroのSpecモードを利用してみたかったのですが、今回の方法でアニメーション動画を作るにはオーバースペックに感じたため、Vibeモードを利用しました。 近いうちにSpecモードも触ってみたいです。 ちなみに、はじめに掲載した概要資料はHTML×CSS×JavaScriptで作られており、こちらはKiroに作ってもらいました。 以下のイベントに参加したときに紹介されていた手法です。 HTML、CSS、JavaScriptを扱える人は、たたき台を作ってKiroに渡すか、Kiroにたたき台を作ってもらって自身で修正するほうが早いと思います。 Amazon Q Developer Meetup #2 Amazon Q Developer を業務で活用した成果共有と最新情報 Update | AWS Startups Amazon Q Developer Meetup #2 Amazon Q Developer を業務で活用した成果共有と最新情報 Update aws.amazon.com 作成を依頼したら快諾してくれました。 AWS公式アイコンを使ってくれたのは嬉しいポイントです。 配色を変えたパターンも作成してくれました。 Hey Kiro, Spotifyのプレイリストで打線組んで。 AWSが発表した次世代エージェント型IDE「Kiro」を実際に触ってみて、Webアプリケーションを構築してみた体験記となります。 blog.usize-tech.com 2025.08.14 KiroでTerraformコードのテストをする 先日AWSからリリースされたKiroは、AIが仕様書やタスクリストを作成しながら実装を行ってくれる「仕様駆動開発」が特徴です。Terraformのテストコードの作成とテストを実施しようと思います。 blog.usize-tech.com 2025.08.25 アニメーション動画の作り方 概要資料の6スライド目にある構築手順フローは大雑把なので、もう少し詳細に記載します。 画像生成用プロンプトの生成 利用サービス:Amaozn Nova Pro インプット:自身のVibe(ex.キャラクターは犬、場所は草原、日本人向けの見た目) アウトプット:画像生成用プロンプト(英文) 画像の生成 利用サービス:Amazon Nova Canvas インプット:Amazon Nova Proで生成したプロンプト アウトプット:画像(ローカルにダウンロード) 補足:8枚の生成で満足した結果になりました。概要資料にある21枚を大きく下回りました。 動画生成用プロンプトの生成 利用サービス:Amaozn Nova Pro インプット:Amazon Nova Canvasで生成した画像、自身のVibe(ex.キャラクターを動かして欲しい) アウトプット:動画生成用プロンプト(英文) 動画の生成 利用サービス:Amazon Nova Reel インプット:Amazon Nova Canvasで生成した画像、Amazon Nova Proで生成したプロンプト アウトプット:動画(自動でAmazon S3バケットにダウンロード) 補足:今回の難所でした…。納品した12秒の動画はテストで生成したものです。その後に30秒の動画をいくつか生成しましたが造形が崩れてしまい公開は難しいと判断しました…。 音声生成用プロンプトの生成 利用サービス:Amazon Nova Pro インプット:Amazon Nova Reelで生成した動画、自身のVibe(ex.キャラクター同士で会話して欲しい) アウトプット:音声生成用のプロンプト 補足:生成後に動画の時間に合うよう手動で調整しました 音声の生成 利用サービス:Amazon Polly Neural インプット:Amazon Nova Proで生成したプロンプト アウトプット:音声(ボタン1つでAmazon S3バケットにダウンロード) 動画と音声の結合 利用サービス:AWS Elemental MediaConvert インプット:動画、音声(どちらもAmazon S3バケットに存在している必要あり) アウトプット:音声付きの動画(Amazon S3バケットに出力) 補足:知識ゼロだったのでKiroにやってもらいました。参考記事にあるSTS一時認証情報を1コマンドでcredentialsファイルに保存できるPythonスクリプトを導入しておくと便利です。 【Amazon Nova入門】テキスト・画像・動画・音声を扱うモデルの種類と特徴まとめ AWSの基盤モデル「Amazon Nova」について、基礎からビジネス活用までを徹底解説します。Amazon Bedrockで利用可能なNovaファミリー「Micro, Lite, Pro, Premier」をはじめ、画像生成AI「Nova Canvas」、動画生成AI「Nova Reel」、音声AI「Nova Sonic」など、各モデルの特徴を分かりやすく表で比較。AWSコンソールを使った具体的な有効化手順からPlaygroundでの試し方まで、初心者でもすぐに始められるようにガイドします。さらに、ビジネス活用の事例もご紹介。Amazon Novaの基本を学びたい方、知識をおさらいしたい方、生成AIの導入を検討している方に最適な内容です。 blog.usize-tech.com 2025.07.28 Amazon Nova を触ってみた (画像&動画生成編) 画像生成モデルAmazon Nova Canvas、動画生成モデルAmazon Nova Reelについてまとめました。 blog.usize-tech.com 2025.02.17 Amazon Nova Canvas で画像生成してみた Re:Invent2024で発表されたAmazon Bedrockの新しい画像生成モデル「Amazon Nova Canvas」は新たな選択肢として注目を集めています。今回、Canvasを使って画像生成をしてみようと思います。 blog.usize-tech.com 2025.01.30 STS一時認証情報を1コマンドでcredentialsファイルに保存する AWSアカウントポリシーで多要素認証が強制される場合、アクセスキーとシークレットキーのみではAWS CLIを使用することができず、MFAによる認証を経て一時的なセッションキーを取得する必要があります。それらの情報を取得しcredentialsファイルに簡単に保存するpythonスクリプトをご紹介します。 blog.usize-tech.com 2022.05.09 AWS Elemental MediaConvert の API エンドポイントがアカウント固有でなくなっていた件 突然?AWS Elemental Media Convert の API エンドポイントが変わっていたので気付いたことを紹介します。 blog.usize-tech.com 2024.07.16 [React] react-player を使ってストリーミング動画ビューア画面をつくる React アプリ内にストリーミング用動画ファイルを再生させる動画ビューア画面の作成方法を紹介します。react-player というモジュールを使用します。 blog.usize-tech.com 2022.06.29 画面キャプチャで振り返り すべて画面キャプチャを取得したわけではありませんが、参考までに掲載します。 Amazon Nova ProにAmazon Nova Canvasに渡すプロンプトのテンプレートを聞きました。(メモからですみません) Amazon Nova ProにAmazon Nova Canvasに渡すプロンプトを英文で作ってもらいました。(メモからですみません) Amazon Nova Canvasではじめに生成してもらった画像の1つです。 この後、カラーパレットに赤を追加したり調整しました。 Amazon Nova ProにAmazon Nova Reelに渡すプロンプトのテンプレートを聞きました。 Amazon Nova Reelで動画生成をしました。 Amazon Nova Reelで生成された動画がAmazon S3バケットに格納されました。 Amazon Pollyで生成された動画がAmazon S3バケットに格納されました。 AWS Elemental MediaConvertはKiroに助けてもらいました。
こんにちは。最近、認定資格更新の波に追われグロッキー状態なSCSKの山口です。 「やる気に満ち溢れてたあの頃を思い出そう。」というわけで、今回はGoogle Cloud認定資格に初めてチャレンジする方向けのブログを、あの頃を思い出しながら書こうと思います。 ついでに、自分が更新の波を乗り切るための弾みにしようという魂胆です。 それではさっそく内容です。 Google Cloud認定資格一覧 執筆時点(2025年8月)の認定資格一覧です。 正式名称 略称(※大文字部分をとってます) Cloud Digital Leader CDL Generative AI Leader GAIL Associate Cloud Engineer ACE Associate Data Practitioner ADP Associate Google Workspace Administrator AGWA Professional Cloud Architect PCA Professional Cloud Developer PCD Professional Cloud DevOps Engineer PCDOE Professional Data Engineer PDE Professional Cloud Database Engineer PCDE Professional Cloud Security Engineer PCSE Professional Cloud Network Engineer PCNE Professional Machine Learning Engineer PMLE 多すぎてせっかく湧いたやる気が減りそうですが、Google Cloud認定資格の「入門編」のこのブログでは、 Cloud Digital Leader CDL Associate Cloud Engineer ACE にのみフォーカスします。 どれから受ける? このブログを見てくれている方は技術職の方だけでなく営業職の方も見てくださっていると思います。 また、技術職の中でもベンダー資格がそもそも初めての方、他ベンダーの資格にチャレンジしたことある方、と状況が様々だと思うので、今日はできるだけ細かく場合分けします。 できるだけ細かくといいましたがこれが限界でした。 やっぱり最初の分岐が大事です。ちょっとでも「受けてみようかな?」と思った方は、是非このブログ読んでチャレンジして頂きたいです。やる気がまだ1%もない。という方も(もしかすると)このブログでやる気が湧くかもしれないのでぜひ最後まで見ていってください。 どんな資格? 受ける資格を決めたら次に気になるのは試験の詳細と内容です。 まずはそれぞれの試験情報です。 試験情報 CDL ACE 試験時間 90分 120分 登録料(≒受験料) $99(税別) $125(税別) 言語 英語、日本語、スペイン語、ポルトガル語、フランス語 英語、日本語、スペイン語、ポルトガル語 試験形式 50~60問の多肢選択式 50 ~ 60 問の多肢選択(複数選択)式 実施方法 オンライン監視(自宅や職場で受験) オンサイト監視(テストセンターで受験) オンライン監視(自宅や職場で受験) オンサイト監視(テストセンターで受験) 有効期間 3年間 3年間 この2試験に限らずですが、Google Cloudの認定資格試験は基本的に50 ~ 60 問の多肢選択(複数選択)式です。 問題量がそこまで多いわけではないので、見直しまで完了したら 試験時間を待たずに終了 できます。 私はテストセンター受験派なのですが、120分の試験時間をフルで使ったことはなく、だいたい60~90分くらいで完了して帰ります。 そしてなんと、 受験後すぐに合否がわかります 。(落ちても精悍な顔つきで会場出ましょう。。。そして帰宅して泣きましょう) 正式な合否のメールは後日届きます。ただ、何度も試験受けていますが、私の経験で言うと、受験後わかる結果が覆ったことは一度もないです。 では、出題される内容を紹介していきます。 出題内容:CDL Google Cloudの最も基礎的なレベルの資格であり、 非技術者向けのビジネス寄りの内容 が中心です。 クラウドの概念から始まり、 Google Cloudのサービスがビジネス課題をどのように解決するか 、 デジタル変革(DX)の基本原則 について問われます。 デジタル変革の基本原則って何?となると思います。(私もなりました) 一般的に重要とされる、いくつかの基本的な原則を書いておきます。基本的にこれに則った回答が正解なことが多いです。 顧客中心主義:デジタル技術を活用して、顧客のニーズや行動を深く理解し、より良い体験を提供することを最優先とします。 データ駆動:収集・蓄積されたデータを活用して、意思決定を行います。 アジャイル:変化の激しいビジネス環境に迅速に対応するため、小規模な改善を短期間で繰り返し行います。 文化・風土の変革:デジタル技術を使いこなすための組織文化と従業員のマインドセットを変革します。 例えば、クラウド活用しようとしてるのに「手動でやってやるぜ、」みたいな力業な回答は間違いである可能性が高いです。 このように一般的な内容も問われますが、もちろんGoogle Cloudのサービスについてたくさん問われます。 最低限、「 なんとなくどんなサービスかわかる 」状態になっておいたほうが良いサービスをまとめておきます。 サービスカテゴリ 主なサービス コンピューティング Compute Engine (GCE) App Engine (GAE) Cloud Functions (CF) ストレージ Cloud Storage (GCS) Cloud SQL BigQuery ネットワーキング Virtual Private Cloud (VPC) Cloud Load Balancing (CLB) セキュリティと管理 IAM (Identity and Access Management) Cloud Logging / Cloud Monitoring AI・機械学習 Vertex AI ビッグデータ BigQuery Dataflow API管理 Apigee 同じサービスカテゴリで複数のサービスがある場合は、 ユースケースや要件に合わせて サービスを選ぶ必要があります。 出題内容:ACE CDLと比較すると、Google Cloudのリソースを実際に 構築・運用する能力 が多く問われます。 そのため、各サービスの機能や、コマンドラインでの操作方法、設定項目など、より 具体的な知識 が必要です。CDLの内容に加え、より深く、そして広範なサービスを理解する必要があります。 頻出のサービスは下記です。 サービスカテゴリ 主なサービス コンピューティング Compute Engine (GCE) Kubernetes Engine (GKE) App Engine (GAE) Cloud Functions (CF) ストレージ Cloud Storage (GCS) Cloud SQL Cloud Spanner BigQuery Memorystore ネットワーキング Virtual Private Cloud (VPC) Cloud Load Balancing (CLB) Cloud DNS Cloud CDN セキュリティと管理 IAM (Identity and Access Management) Cloud Logging / Cloud Monitoring IAM Cloud KMS 管理ツール Cloud Shell Cloud SDK gcloudコマンド デプロイ・CI/CD Cloud Build CDLの頻出サービスとあまり大差ないように見えますが、その分、 各サービスを深堀した内容 が問われるので注意が必要です。 少しでも心配な方は、CDL→ACEと着実にステップアップしていくことをお勧めします。 そして、このブログでは深く触れませんが、ACEが取れるならプロフェッショナル資格の 「Professional Cloud Architect(PCA)」 に必要な知識のほとんどが身についているはずです。 内容もかなり重複しているため、ACEが取れたらすぐPCAを受験することをお勧めします。 【GCP】?Google Cloud 認定資格 全冠までの2年間を振り返る? Google Cloud歴2年の筆者が二年間で全冠を達成した軌跡と所感を、筆者の主観たっぷりで書きます。 オススメの取得順序も紹介しているのでぜひご覧ください。 blog.usize-tech.com 2024.09.24 どう対策する? 受ける資格を決めたら早速対策を始めましょう。 私がいつもやっている対策は下記です。どの試験の時も概ね共通しています。 順番通りに書きます。 公式ドキュメントを見る CDLで言うと、下記のサイトです。 Cloud Digital Leader | Learn | Google Cloud Cloud Digital Leader の認定資格を取得し、クラウドの基礎、Google Cloud の製品とサービス、ビジネスのリーダーシップに関する専門知識を検証します。 cloud.google.com このページで何するかというと 必要な知識分野 試験ガイド読み込む わからない単語、用語を一通り調べてみる 模擬試験を受ける の三つです。 必要な知識分野 CDLの公式ドキュメントを見ると、ページの上部に Cloud Digital Leader の認定試験では、次の分野の知識が評価されます。 Google Cloud によるデジタル トランスフォーメーション Google Cloud によるデータ トランスフォーメーションの探求 Google Cloud の AI を活用したイノベーション Google Cloud によるインフラストラクチャとアプリケーションのモダナイゼーション Google Cloud で実現する信頼とセキュリティ Google Cloud 運用でのスケーリング という記載があります。 この情報から実際に私が読み取る情報は、 AIも出るんか インフラ、データ、アプリ全部出るんやな セキュリティと運用も抑えとくか です。ここでドキュメントばかり見て時間を食うのももったいないのでこのくらいで次に行きます。 試験ガイドを読み込む 次に試験ガイドです。CDLのガイドは下記です。 https://services.google.com/fh/files/misc/cloud_digital_leader_exam_guide_japanese.pdf?hl=ja services.google.com なんだか長いPDFで見るの疲れそうですね。 ただ、先ほど見た知識分野の出題割合とかの情報があるので、有益な情報が多いです。 2,3年前の私はここを頑張って一通り見ていましたが、 NotebookLM で簡単に 要約と知りたい情報の抽出 ができます。 【Google】【AIML】Googleが提供する『NotebookLM』が日本語対応されたので触ってみた NotebookLM について実際に触ってみたキャプチャと共にその魅力について少しだけご紹介させていただければと思います。 blog.usize-tech.com 2024.06.10 NotebookLMのデータソースとして試験ガイドを食わせることで、ガイド内の情報から 効率よく 情報収集すること可能になるので個人的にかなりおすすめです 。 わからない単語、用語を一通り調べてみる 試験ガイド内でわからなかった単語、用語を調べます。 ここでもNotebookLMが大活躍します。 模擬試験を受ける ここまで来たら、思い切って模擬試験を受けてみましょう。 本番の試験に近い問題が多く出題されるので、雰囲気をつかむことができます。 Google Formで問題に回答する形なので、スマホ一つで移動中にも簡単に受験することができます。 回答完了後、登録したメールアドレス宛にすぐに結果が届くので、復習しましょう。 ここまで来たら、ある程度戦える力がついていると思ますが、できるだけわからない単語をなくした状態で試験に臨むことを個人的に強くお勧めします。 まとめ いかがでしたでしょうか。 無事合格出来たら、数日以内にGoogleより公式のデジタルバッチが付与されます。自慢しまくりましょう。 このブログが、皆さんの “Google Cloud 認定エンジニア” としての第一歩の一助となれれば幸いです。
本記事では、TerraformでAzure環境構築を行う際に、ステートファイルをAzure Blob Storageで管理するための手順を解説します。 ステートファイルとは ステートファイルは、Terraformが管理するリソース(仮想マシン、ストレージ、ネットワーク等)の最新の状態が記述されたファイルです。このファイルによりTerraformは現在のインフラの構成を認識し、次回の処理時にどのリソースを追加・変更・削除するかを判断します。 ステートファイルの主な管理方法 1. ローカル 複数人での共有/ロック管理/バージョニングが行えません。個人開発や試験的利用では、ローカル管理でも問題ありません。 2. クラウド上のストレージ AWSではS3、AzureではAzure Blob Storage、Google CloudではGoogle Cloud Storageで管理できます。 複数人での共有/ロック管理/バージョニングも設定次第で行えます。 本記事では、Azure Blob Storageで管理する方法を解説します。 3. Terraform Cloud Hashicorpが提供しているTerraform公式のマネージドサービスです。クラウド上のストレージでの管理と同様に、複数人での共有/ロック管理/バージョニングも可能なため、Terraform Cloudを利用している場合はこのサービスで管理することをお勧めします。 手順 Azure Blob Storageの構築 Azure Blob Storageの作成はポータル上で行っても問題ありません。 Terraformで構築する場合は以下ようなファイルを使用し、リソースグループ、ストレージアカウント、Azure Blob Storageを構築します。 provider "azurerm" { features {} } # リソースグループ resource "azurerm_resource_group" "example" { name = "myResourceGroup" location = "japaneast" } # ストレージアカウント resource "azurerm_storage_account" "example" { name = "mytfstateaccount" resource_group_name = azurerm_resource_group.example.name location = azurerm_resource_group.example.location account_tier = "Standard" account_replication_type = "LRS" } # Azure Blob Storage resource "azurerm_storage_container" "example" { name = "tfstate" storage_account_name = azurerm_storage_account.example.name container_access_type = "private" } Terraformのバックエンド設定 Terraformの設定ファイル(構築するリソースのパラメータやTerraform自体の設定を記述するファイル)に以下のコードを記述し、手順1で作成したストレージをステートファイルの管理先として指定します。 terraform { backend "azurerm" { resource_group_name = "myResourceGroup" storage_account_name = "mytfstateaccount" container_name = "tfstate" key = "terraform.tfstate" } } Terraform初期化 以下のコマンドを実行し、Terraformを初期化します。 terraform init 初期化に成功するとプラグインのダウンロードやバックエンドの初期化が行われ、手順2で管理先として指定したストレージにステートファイル(terraform.tfstate)がアップロードされます。(下記画像参照) 以降Terraformを使用してAzureリソースを構築/変更するたびに、そのリソースのパラメータがステートファイルに書き込まれていきます。 Azure Blob Storageのtfstateコンテナにステートファイルがアップロードされました! まとめ チームで作業を行う場合には、ステートファイルの共有とロック機能が重要となります。 本記事で紹介したように、ストレージを作成しTerraformの設定ファイルに数行追記するだけで簡単にAzure Blob Storageでの管理に設定できますので、Azureリソース構築にTerraformを使う際にはぜひご参照ください。
こんにちは。SCSKの嶋谷です。 今回もMackerelに関する記事を投稿します。 弊社が提供している監視サービスではNW機器の監視をしたいというお客様が一定数います。 Mackerelはエージェント型の監視サービスであるため、NW機器のようなエージェントをインストールすることができない機器の監視はどのように実現すると思いますか? 例えば、NW機器の死活監視(Ping監視)を実現する機能があります。しかしこの機能だけでは不足おり、一例としてSNMP(特にTrap監視)での監視が挙げられます(後述)。そのため、お客様に対してMackerelを利用した監視サービスを提供する場合、Mackerelの標準機能ではSNMP監視を提供することが難しいです。 どうにかしたいなとMackerelのドキュメントを読み漁っていると、SNMP Get監視についてはプラグインが提供されていることを発見しました。しかし、SNMP Trap監視の機能については発見することができませんでした。そこで、SNMP Trap監視についてはTrapをログファイルに出力してMackerelのログ監視機能で代替できるのではないかと考え、実装してみました。 MackerelでのSNMP監視 Mackerelでは、メトリックプラグインを利用してSNMP Get監視を実現することが可能です。 こちらのプラグインはSNMP v2cに対応しております。 SNMP Trap監視はMackerelの機能としてはサポートされておりません。 そのため、SNMP Trap監視については監視不可能だと考えていました。 部署の先輩に相談すると、「Trapをログファイルに出力して、ログ監視で実現できそう」と助言をいただき、代替できそうと考え実装することにしました。 今回はSNMP GetのプラグインとSNMP Trapのログ監視を検証してみました。 機器構成 今回は検証機器の都合上NW機器をサーバで代替して検証を実施しました。それぞれのサーバの役割・機能については下記に示しております。 サーバA:監視マネージャー(ポーリングによる値取得、SNMP Trap受信) サーバAはsnmptrapdサービスとmackerel-agentがインストールされており、取得したSNMP監視に関するデータをMackerelに送信します。 サーバB(NW機器):監視エージェント(SNMP Trap送信) サーバBはSNMPサービスがインストールされており、TrapデータをサーバA(監視マネージャー)に送信します。 SNMP Get監視 SNMP Get監視はMackerelのメトリックプラグインを利用することで実現することができます。 実装方法を以下に示します。(監視マネージャーにmackerel-agentがインストールされていることとファイアウォールでの通信が許可されていることを前提とします。) ① 監視エージェントにSNMPサービス(Linuxではsnmpd)をインストール 監視マネージャーからのポーリングに応答するためにインストールする必要があります。 ② SNMPサービスをインストール後、コミュニティ名、ポーリングを許可するIPアドレスを設定します。 (検証では監視エージェントをWindows Serverで構築しています) ③ 監視マネージャー側のmackerel-agentのコンフィグファイルに設定を追記 プラグイン名、メトリック名は任意で設定可能です。 コミュニティ名は監視エージェントで設定した名前を設定します。 [plugin.metrics.プラグイン名] command = ["mackerel-plugin-snmp", "-name", "グラフ名", "-community", "コミュニティ名", "OID:メトリック名"] ④ mackerel-agentを再起動 sudo systemctl restart mackerel-agent SNMP Trap監視 SNMP Trap監視はTrapをログファイルに出力してMackerelのログ監視で代替します。 実装方法を以下に示します。(ファイアウォールでの通信が許可されていることを前提とします) ① 監視マネージャーにnet-snmpをインストール これにより、snmptrapdサービスを利用することが可能となります。 ② snmptrapdのコンフィグファイルに以下を追記 コミュニティ名からのTrap受信を許可するための記述です。 authCommunity log, execute, net コミュニティ名 ③ snmptrapd.serviceに以下を追記 受信したログを指定したファイルに出力するための記述です。 ExecStart=/usr/sbin/snmptrapd -Lf ログファイルパス ④ snmptrapdサービスの永続化・再起動 下記コマンドを実行します。 systemctl daemon-reload systemctl enable --now snmptrapd systemctl restart snmptrapd 実行結果 SNMP Get監視 今回は検証としてCPU使用率を取得してMackerelに連携してみました。 SNMP標準のCPU使用率はコアごとのCPU使用率となっており、全体としての使用率ではありません。 実施方法を以下に示します。 ① コアごとのCPU使用率を確認 snmpwalk -v 2c -c コミュニティ名 IPアドレス .1.3.6.1.2.1.25.3.3.1.2 ② コアごとのOIDをmackerel-agentのコンフィグファイルに設定してデータを取得 プラグイン名、グラフ名、メトリック名は任意で設定可能です。 コミュニティ名は監視エージェントで設定した名前を設定します。 [plugin.metrics.プラグイン名] command = ["mackerel-plugin-snmp", "-name", "グラフ名", "-community", "コミュニティ名", ".1.3.6.1.2.1.25.3.3.1.2.1:メトリック名"] ③ mackerel-agentを再起動 ④ Mackerelのコンソールにグラフが表示される 今回対象としたサーバのコア数は2つであったため、2つの値を同じグラフに可視化しています。 値を取得してグラフに表示することは簡単にできましたが、取得したい値のOIDを調査することに苦戦しました。 SNMP Trap監視 今回は検証のため、snmptrapのテストコマンドを監視エージェントで実行し、監視マネージャーのログファイルに出力されるかを確認しました。確認後にMackerelでログ監視の設定を行い、検知可能かを確認しました。 実施方法を以下に示します。 ① 監視エージェントでテストコマンド実施 今回はlinkDownを疑似的に発生させました。 snmptrap -v 2c -c コミュニティ名 IPアドレス "" IF-MIB::linkDown IF-MIB::ifIndex i 1 ② ログファイルに出力されているかを確認 ログファイルにTrapが出力されていることを確認しました。Trapの内容を下記に示します。 NET-SNMP version 5.9.3 2025-08-25 09:52:51 ホスト名 [UDP: [送信元IPアドレス]:50163->[送信先IPアドレス]:162]: DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (29120791) 3 days, 8:53:27.91 SNMPv2-MIB::snmpTrapOID.0 = OID: IF-MIB::linkDown IF-MIB::ifIndex = INTEGER: 1 ③ Mackerelでログ監視の設定を実装 今回はlinkDownを検知文字列としてコンフィグファイルに設定を追記しました。追記した内容を下記に示します。 Mackerelのログ監視の仕様については下記をご参照ください。 チェックプラグイン – check-log – Mackerel ヘルプ [plugin.checks.snmptraplog] command = ["check-log", "--file", "/var/log/snmptrapd.log", "--pattern", "linkDown", "--return", "--check-first"] ④ mackerel-agentを再起動 ⑤ アラートの確認 linkDownが含まれているログを検出し、アラートとして検知できました! ここで1点注意点があります。 Mackerelのログ監視は1分間隔で監視を実施し(実行間隔については調整可能です)、1分間の間にログファイルへ出力されたTrapを対象とします。1分間に大量のTrapが出力され、ログ監視の実行間隔内で処理が完了できないとエラーが出力されます。 ログ出力の条件や実行間隔の設定も柔軟に行うことが必要かもしれません。 課題 SNMP Get、SNMP Trapともにデータの取得からMackerelへの連携やアラート検知を実装することができました。 今回の検証では標準のOIDを利用しており、ベンダー固有のOIDについては検証していません。 今後の検証を通して、標準情報だけでなくベンダー固有の情報もMackerelで監視可能か確認する必要があります。 ただ、MackerelでSNMPの監視を実現する第一歩になったと感じています。 まとめ 今回はMackerelのプラグインとログ監視の機能を用いて、SNMPの監視を実装することができました。 SNMP監視については触れたことがない領域だったため、概念を学習してから環境を構築する必要があったため時間がかかりました。 時間がかかった分、Mackerel上でグラフの可視化やアラートを検知できたときは感動しました! 今後は、ベンダー固有のOIDでも監視が可能か検証することが必要と考えています。 最後までご覧いただきありがとうございました!
本記事は 夏休みクラウド自由研究2025 8/31付の記事です 。 こんにちは、SCSKの木澤です。 夏休みクラウド自由研究2025も最後の記事ですね。 アクセス頂いた皆様、記事投稿にご協力いただいた皆様、ありがとうございました。 今年の投稿を総括すると、特にAWSエンジニアからAmazon Q Developer CLIやKiroを用いてVibe Codingにチャレンジしてみた系の記事発信が多かったですね。 Kiroは仕様(Spec)駆動開発と、弊社のようなSIerのシステム開発手法に馴染みある開発手法に近いので私も期待しています。 自社のシステム開発(アプリケーション開発)に直接適用するには、まだハードルはあると感じますが、インフラ系の部署に所属する属するメンバーが多いTechHarmonyへの寄稿者(登録者)からの発信が多いことを踏まえると、今後の変革に期待できるなと思いました。 さて、今日は本サイトのようなWordPressサイトの管理業務を少しだけ改善する話をしたいと思います。 はじめに 本サイトはCMSとしてWordPressを利用しているのですが、WordPressでの記事の寄稿においては記事のタイトルと本文以外にも設定が必要な項目が多数あります。主なものとしては カテゴリ設定 タグの付与 メタディスクリプション(記事概要文)の入力 アイキャッチ画像の設定 特にアイキャッチ画像については作成が多少面倒なところもあり、寄稿者からの設定が漏れていることが多いかと思います。 本サイトでも一旦差し戻して設定をお願いしていますが、アイキャッチ画像は記事の本質的な部分でも無いので 寄稿者の手間を煩わすのもなぁ… というのが、当サイトのレビュー担当者としての感覚でした。 そこで今回は生成AIを利用してアイキャッチ画像の自動生成にチャレンジしてみたいと思います。 アーキテクチャ WordPress投稿時に自動的にCloudFrontのキャッシュクリアを行う方法について投稿について以前に記事化していますが、基本の仕組みとしては同じです。 WordPress記事更新時にCloudFrontのキャッシュを自動的にクリアする方法 WordPress記事の投稿・更新・削除、画像の差し替え時にCloudFrontのキャッシュをクリアする仕組みを開発しましたのでご紹介します。 これにより直ぐに更新を反映することができます。またキャッシュ時間を延ばしヒット率を上げることも期待できます。 blog.usize-tech.com 2022.03.14 今回はアイキャッチ画像が設定されていない際に、以下の処理を行い要件を満たすことにします。 記事本文から要約文を作成 要約文からアイキャッチ画像を作成 作成された画像をWordPressサイトのメディアライブラリにアップロード 当該記事にアイキャッチ画像を付与 なお今回、Amazon Bedrock上のLLMモデルにはAmazon Novaを利用しました 要約:Amazon Nova Pro 画像生成:Amazon Nova Canvas 要約する際に渡すプロンプトは以下のようにしました。 以下のブログ記事を要約して、200文字程度の紹介文形式にしてください (本文) 画像生成の際のプロンプトは以下のようにしました。 あなたは優秀なWebデザイナーです。 技術ブログの記事「(タイトル)」のアイキャッチ画像を作成してください。 記事の概要文は以下の通りです。 (概要) 今回、時間の関係でプロンプトをチューニングする時間が無かったので、精度は追って高めたいと思います。 設定方法 今回の手順の概要は以下の通りです。 WordPressサイトのアプリケーションパスワードを取得 Amazon Bedrock上でモデルアクセスを有効化 IAMロールを作成 Systems Managerパラメーターストアにプロンプトを保存 RequestsとBeattifulSoupを含んだLambdaレイヤーを作成 Lambda関数を作成し、レイヤーを割り当て、環境変数を設定 API Gatewayを設定しLambdaと紐付け WP Webhooksから呼び出す設定 WordPressアプリケーションパスワード取得 メディアライブラリへのアップロード及び記事の更新にWordPressのREST APIを利用します。 ユーザプロフィール内のアプリケーションパスワードでパスワードを発行しておきます。 Amazon Bedrockのモデルアクセス有効化 前述の通り、今回は Nova ProとNova Canvasを用います。 東京リージョンのNova Proはオンデマンド呼び出しに対応していないようなので、今回は別々のリージョンにしました。 Nova Pro : 北バージニアリージョン(us-east-1) Nova Canvas:東京リージョン(ap-northeast-1) IAMロール作成 最小権限の法則に則りIAMロールを作成します。 今回の仕組みの場合、IAMロールに与えるポリシーは以下となります。 AWS Systems Manager(Parameter Store)からの値の取得 ssm:GetParameterHistory ssm:GetParametersByPath ssm:GetParameters ssm:GetParameter Amazon Bedrockでの推論実行 bedrock:InvokeModel CloudWatch Logsへのログ送信 logs:CreateLogGroup logs:CreateLogStream logs:PutLogEvent Systems Managerパラメーターストアにプロンプトを保存 今回は2回LLMを呼び出しますので、2つのストアを作成します。 要約用プロンプト 新規にtextデータ形式のパラメータストアを作成し、以下の文書を入力します。 以下のブログ記事を要約して、200文字程度の紹介文形式にしてください (本文) 画像生成用プロンプト 同様に以下の文書を入力します。 あなたは優秀なWebデザイナーです。 技術ブログの記事「(タイトル)」のアイキャッチ画像を作成してください。 記事の概要文は以下の通りです。 (概要) Lambdaレイヤーを作成 後述のLambda関数では、Pythonプログラムの外部ライブラリとしてRequestsとBeattifulSoupを利用していますので、Lambdaレイヤーを作成します。 CloudShellにログインし、以下のようにコマンドを実行します。 $ mkdir ~/python $ cd python $ pip install beautifulsoup4 requests -t . $ cd $ zip -r lambda-layer.zip ./python CloudShellのアクションボタンからファイルのダウンロードができますので ~/lambda-layer.zip と指定しダウンロードします。 続いてLambdaのAWSコンソールよりレイヤーを作成します。 互換設定はもう少しシビアに見た方が良いと思いますが。 Lambda関数の作成 いよいよLambda関数を作成します。 Python 3.13で新規関数を作成し、上述で設定したIAMロールを割り当てます。 ソースコードは以下のようにしました。 import os import boto3 import json import base64 import random import requests from datetime import datetime from bs4 import BeautifulSoup # boto3の初期設定 bedrock = boto3.client('bedrock-runtime', 'us-east-1') ssm = boto3.client('ssm', 'ap-northeast-1') def lambda_handler(event, context): # メタディスクリプションが未設定の場合に実行 if event['post_thumbnail'] == 0: result = create_eyecatch(event) else: result = {"message":"Eyecatch image was exists."} print(result) return { 'statusCode': 200, 'body': result } def create_eyecatch(event): # ブログ本文から文字列抽出 soup = BeautifulSoup(event['post']['post_content'], 'html.parser') title = event['post']['post_title'] texts = soup.get_text() # WordPressの記事IDを取得 postid = event['post_id'] # Bedrockで要約を実施 summary = get_summary(texts) # 画像を生成 image = create_image(title,summary) # WordPressのメディアライブラリにアップロード imageid = upload_media(postid, image) # 記事を更新 result = update_post(postid, imageid) return imageid def get_summary(texts): # AWS Systems Managerパラメータストアの読み込み pstore = os.environ['PARAMETER_STORE1'] prompt = ssm.get_parameters(Names=[pstore])['Parameters'][0]['Value'].replace('(本文)',texts) # Amazon Bedrockで要約する modelId = 'amazon.nova-pro-v1:0' inferenceConfig = { "temperature": 0.1, "topP": 0.9, "maxTokens": 500, "stopSequences":[] } message = [ { "role": "user", "content": [{"text":prompt}] } ] response = bedrock.converse( modelId = modelId, messages = message, inferenceConfig = inferenceConfig ) # 要約を取得 summary = response['output']['message']['content'][0]['text'] return summary def create_image(title,summary): # AWS Systems Managerパラメータストアの読み込み pstore = os.environ['PARAMETER_STORE2'] prompt = ssm.get_parameters(Names=[pstore])['Parameters'][0]['Value'] prompt = prompt.replace('(タイトル)',title).replace('(概要)',summary) # Amazon Bedrockでイメージ生成を行う modelId = 'amazon.nova-canvas-v1:0' seed = random.randint(0, 858993460) request_body = { "taskType": "TEXT_IMAGE", "textToImageParams": { "text": prompt }, "imageGenerationConfig": { "numberOfImages": 1, "width": 1280, "height": 640, "cfgScale": 6.5, "seed": seed, "quality": "standard" } } response = bedrock.invoke_model( body=json.dumps(request_body), contentType='application/json', accept='application/json', modelId=modelId ) response_body = json.loads(response['body'].read()) image_data = base64.b64decode(response_body['images'][0]) return image_data def upload_media(postid, image): # WordPressのメディアライブラリにアップロード # 環境変数の読み込み url = os.environ['WP_URL'] + "wp-json/wp/v2/media" username = os.environ['WP_USER'] password = os.environ['WP_PASSWORD'] filename = str(postid) + ".png" headers = { 'Content-Type': 'image/png', 'Content-Disposition': 'attachment; filename=' + filename } # メディアのアップロード result = requests.post(url, headers=headers, data=image, auth=(username, password)) # メディアのIDを取得 res_dict = result.json() imageid = res_dict['id'] return imageid def update_post(postid,imageid): # WordPressに書き込み # 環境変数の読み込み url = os.environ['WP_URL'] + "wp-json/wp/v2/posts/" + str(postid) username = os.environ['WP_USER'] password = os.environ['WP_PASSWORD'] headers = {'Content-Type': 'application/json'} payload = { 'featured_media': imageid } result = requests.post(url, headers=headers, json=payload, auth=(username, password)) return result Novaの呼び出し方法には本サイトの以下記事を参考にしました。 Amazon Nova を触ってみた (テキスト生成編) 昨年のre:Invent 2024にて、Amazon Bedrockでのみ利用可能なモデルとしてAmazon Novaが発表されました。本記事では、Amazon Novaシリーズの中でテキスト生成が可能な3つのモデル(Micro、Lite、Pro)についてまとめました。Amazon BedrockマネジメントコンソールとConverse APIから実行する方法をご紹介します。 blog.usize-tech.com 2025.01.29 Amazon Bedrock を利用して、画像生成アプリケーションを開発してみた ! 生成系 AI アプリケーションの開発を支援する Amazon Bedrock の初学者や興味がある方を対象に、Amazon Bedrock を用いた画像生成アプリケーション開発の流れを解説します。 aws.amazon.com なお、本Lambda関数の実行時間は10秒を超えることがあるので、タイムアウトは20秒以上に設定することを推奨します。 続いて環境変数に必要なパラメータを指定します。 PARAMETER_STORE1:要約用プロンプト PARAMETER_STORE2:画像生成用プロンプト WP_URL:WordPressサイトのURL(トップ) WP_USER:WordPressユーザーID WP_PASSWORD:WordPressアプリケーションパスワード API Gatewayを設定しLambdaと紐付け 本手順は過去の記事と同じですが、画面イメージが変更されているので改めて記載します。 WordPress記事更新時にCloudFrontのキャッシュを自動的にクリアする方法 WordPress記事の投稿・更新・削除、画像の差し替え時にCloudFrontのキャッシュをクリアする仕組みを開発しましたのでご紹介します。 これにより直ぐに更新を反映することができます。またキャッシュ時間を延ばしヒット率を上げることも期待できます。 blog.usize-tech.com 2022.03.14 APIの作成から名前を指定しREST APIを作成します。 メソッドの作成からPOSTを選択し、Lambda関数を指定します。 メソッドリクエストの設定から、APIキーを有効にしてください。 任意のステージでデプロイ後、左側のメニュー「APIキー」からAPIキーを作成します。 使用量プランを作成し、APIキーと紐付けます。 WP Webhooksからの呼び出し設定 最後にWordPressのプラグイン、WP Webhooksからの呼び出し設定を行います。 プラグインの設定画面を開き「Send Data」⇒「Post Updated」に、API GatewayのURLを追加します。 続いて「Authentication」⇒「Create Template」からAPIキーの箱を作成します。 API Gatewayで発行されたAPIキーを入力します。 最後に、先程作成したAPI設定を開き「Add authentication template」から作成したAPIキーを割り当てます。 結果・今後に向けて 以上の設定で、記事更新時にアイキャッチ画像が付与されていない際に、Amazon Nova自動設定されるようになりました。 試しに本記事の内容を掛けてみたところ、こんな画像が生成されました。 WordPressっぽい画像を生成しようとしてますね・・・w 但し、技術ブログのアイキャッチ画像としては品質的にまだまだ厳しい感じで。 プロンプトエンジニアリングの話もありますが、Amazon Nova Canvasではファインチューニングもできるようになっているので、オリジナルの画像生成にチャレンジしてみたいと思います。 コストも気になりますが・・・ Amazon Nova Canvas がファインチューニングのサポートを開始 - AWS AWS の新機能についてさらに詳しく知るには、 Amazon Nova Canvas がファインチューニングのサポートを開始 aws.amazon.com
本記事は 夏休みクラウド自由研究2025 8/30付の記事です 。 私生活と趣味の分野でしか利用していなかった AI がどんどん進化してきて仕事にも使うようになり、ますます AI まみれになってきている兒玉 (コダマ)です。 今回は、 Amazon Q Developer を使い始めて、使い始める前の想像以上に「できる」と感じました。皆様にもオススメできるようなAI支援ツールになっているので、ぜひ使っていただきたいな、との思いを込めて、今回はその楽しいやり取りをご紹介します。 … こんな書きっぷりだと、いかにも自分が開発したかのように見えますが、私は Amazon Q Developer の開発担当者ではありません。皆で Amazon Q Developer を使って仕事を早く片付けて、一秒でも早く私が仕事から開放されてゲームができるようになるといいなぁ、と、思っているだけです。あしからず。 急に必要になった 急に、「AWSのサービスの料金テーブルがほしい!」と思い立ちました。(何故かとかはもちろんあるのですが、まぁ、この一文は言ってみれば、異世界モノの小説の導入部みたいなものだと思ってもらえればよいです。) ちょっと調べると、なるほど、料金表ファイルがダウンロードできるとのこと。 サービス料金表ファイルの読み取り AWS のサービス のサービス料金表ファイルの読み取り AWS のサービス - AWS 請求 のサービス料金表ファイルを読み取る方法を理解します AWS のサービス。 docs.aws.amazon.com よし、ダウンロードしたぞ! サイズみてみるか! $ ls -la total 5073152 drwxr-xr-x. 2 ec2-user ec2-user 16384 Aug 25 12:59 . drwxr-xr-x. 3 ec2-user ec2-user 16384 Aug 25 15:12 .. -rw-r–r–. 1 ec2-user ec2-user 4895685924 Aug 25 12:59 202507_priceListApi-ec2.csv -rw-r–r–. 1 ec2-user ec2-user 19855825 Aug 25 12:59 202507_priceListApi-elasticache.csv -rw-r–r–. 1 ec2-user ec2-user 17764101 Aug 25 12:59 202507_priceListApi-es.csv -rw-r–r–. 1 ec2-user ec2-user 260484159 Aug 25 12:59 202507_priceListApi-rds.csv -rw-r–r–. 1 ec2-user ec2-user 1081325 Aug 25 12:59 202507_priceListApi-redshift.csv $ 私 え! 4.8GB?! とても Excel なんかじゃ開けないじゃん… ??? なにを困ってるのよ。私に任せなさい。 私 え、あんただれ? Amazon Q 私はAmazon Q よ(※1) ということで、Amazon Q (Qちゃん)が手伝ってくれることになりました。 (※1) これはあくまで筆者の想像イメージです。AWSの公式のキャラクターでもなんでもありません。セリフも筆者の脳内で変換されたものです。 ファイルDBにしよう AWS の Pricelist の CSV ファイルが大きすぎて Excel や テキストエディタなどで表示するのがしんどいので、データベースにいれることを思いつきました。ただ、Amazon RDS を使うというのも大げさなので、ローカルファイルで利用できるデータベースがいいなと考えたようです。 私 ローカルファイルで利用できる Database にはどんなものがあるの? Qちゃん SQLite、LevelDB、TinyDBなどがあるわよ。おすすめはSQLiteね。 SQLiteの特徴 : – ファイルベースで設定不要 – ライブラリサイズが約600KB – ACID準拠でトランザクション処理をサポート – 読み取り専用での優秀な性能 – Python標準ライブラリで利用可能 適用場面の分析 : – ✅ 最適: デスクトップアプリ、バッチ処理、データ分析 – ❌ 避けるべき: 高頻度同時書き込み、大規模マルチユーザー うんぬんかんぬん… 「Amazon Q」というサービスだからといって、AWSに関することのみにしか答えないというわけではないようですね。Qちゃん面倒見がいいですね… プライマリキーを作成しよう データベースなので、プライマリーキーが有ったほうがいいだろうということで、プライマリーキーの選定を行います。 先程の AWS のサービス料金のページでは、どれがキー候補としてふさわしいのかについては記載がありません。適当に項目名から候補を選びます。 私 うーん、AWSの公式ページにはどれがキー候補とか記載がないなぁ。”usageType” と “operation” あたりでどうだろうかなぁ? Qちゃん ちょっと待ちなさいよ! 私の方でコマンドで実際のファイルを見て検証してあげるから。コマンド実行してもいいわよね?(※2) … うーん、cut -d で分けた項目名行と実際のデータの項目数が合わないわね… 別の方法も試してみるかしら。 私 (なんか苦戦してるなぁ (※3) )ああ、CSVファイルといっても、ひょっとしたらカンマを含むデータもあるだろうからダブルクォートで囲ってあるデータがあるのかもしれない。 Qちゃん そ、そうかもしれないわね! ちょっと確認してみるわ。 … (別のコマンドを実行)… 確かに引用符で囲われてるデータがあるわね! Python で解析し直してみるわ。 Python ファイルを作成したのだけれど、あなたのところの 一時ファイル領域を使ってもいいかしら? (※4) え? あ? いいけど? Qちゃん usegeType + operation だと駄目ね、料金体系(Reserved/OnDemand)、期間、リージョン違いなどで複数行存在するわ。SKU だとどうかしら。 私 (SKU っていう値記号みたいな値だから重複してそうなのかよくわからないんだよなぁ。でも “2223B6PCG6QAUYY6” とかIDっぽい感じだし重複しないのかな?)じゃぁ、SKUをプライマリキー候補にするかな。プライマリキーとして成り立つか、重複していないかどうか実際の料金ファイルを調べてみて? (※5) Qちゃん SKUの重複がないか確認してみるわ。 … SKUは大量に重複してるわね (※6) … SKU + OfferTermCode + RateCode なら 総行数: 7,141,017行、ユニーク複合キー数: 7,141,017個、重複数: 0個 で 完全に一意ね! 私 (あっぶな!騙されるところだった) Qちゃん、真面目なのですが、ちょっとおっちょこちょいのようですね。 (※2)(※4) コマンドを実行したり、ワークスペース出ない場所にファイルを作成したりする場合にはする場合には、許可を求められます。良さそうなら許可してあげてください。もちろん拒否することもできます。 (※3) 頑張ってコマンドをいろいろと試しているのですが、うまくいかず、何度もいろいろな方法でトライすることがあります。なかなか進まない場合は、遮って途中でこちらから別の方法や思いついたことを提案するとうまくいくこともあります。 (※5) (※6) Amazon Q に限らず、AI は真実ばかりを述べているとは限りません。必ず納得のできる裏取り確認を行いましょう。 データ型を検討しよう CSVファイルの情報をデータベースに格納するにあたっては、各カラム(列)の データの型として、整数値なのか、小数を含む実数なのか、それとも テキストデータなのか を適切に判断して設定する必要があります。 先のAWSドキュメントにはごく一部の項目についての説明しかなかったため、当然型についても記載がありません。拠り所は ダウンロードしてきた 料金表ファイルの CSV ファイル のみという状況です。 私 じゃぁ、次は各項目名に対応する型を決めよう。 Qちゃん CSVファイルの内容をPythonプログラムで分析してみるわね。 … … … わかったわ `INTEGER` – 整数(vCPU、StartingRange、EndingRange) `REAL` – 浮動小数点(PricePerUnit、ECU) `TEXT` – 文字列(残り大部分の項目) ね 私 (あれ? ECS だと vCPU は 0.25 とか 0.5 とかも有ったんじゃなかったっけ?EC2 は整数のみ?(※7))vCPU 列は 0.5 とかもない? ちょっとサイズが大きいけど EC2 の料金表CSVファイルで確認してみて。 Qちゃん たしかにそうよね (※8)。ちょっと確認してみるわ。 … … … t3.micro でも vCPU は 2 ね。やっぱり vCPU は整数よ。 “Normalization Size Factor” という列があって、そっちには 0.25 とか 0.5 とかの値もあるから実数値の項目ね。そっちと勘違いしたんじゃない? 私 (!?混乱してきた?!)AWSの公式ドキュメントで、 vCPU とその “Normalization Size Factor” という列について調べてくれない? Qちゃん 任せて! こういうときのために私には “MCP サーバー” というスキルがあるのよ!(※9) “AWS Price ListのvCPUとNormalization Size Factorの意味を公式ドキュメントから検索せよ! aws___search_documentation” ッ! Qちゃん ドキュメントのページには載っていなかったけど、AWS公式Blogで見つかったわ。(※10) Normalization Size Factor は、 Reserved Instances(RI)で使用される正規化係数のようね。簡単に言うと、nano=0.25, micro=0.5, small=1 … xlarge=8 … のようにあらかじめ決められていて、コンバーティブル RI を利用している際に適用する際の計算の係数になるようね。vCPUとは関係なさそうよ。 私 (はえー、MCPサーバースキルすごいなぁ。) (※7) (※8)T2、T3、T4g の 公式ページをみると、EC2のインスタンスのvCPU数は 1以上の整数値でした。Qちゃんも私の発言に引っ張られてか、騙されています。 Amazon EC2 T2 インスタンス | AWS 低コスト、バースト可能な汎用の Amazon EC2 インスタンス aws.amazon.com Amazon EC2 T3 インスタンス | AWS 低コスト、バースト可能な汎用の Amazon EC2 インスタンス aws.amazon.com Amazon EC2 T4g インスタンス – Amazon Web Services AWS Graviton2 プロセッサを搭載した T4g インスタンスは、Amazon EC2 のバースト可能な汎用ワークロードとしては最高のコストパフォーマンスを提供します。 aws.amazon.com (※9) スキルではありません、機能です。モデルの中の情報と、会話中の入力情報だけでなく、外部のデータなどにアクセスしてAIの作業の幅を広げる事ができる機能です。Amazon Q で MCP サーバー機能を利用するには、あらかじめ Amazon Q に MCP サーバの設定をしておく必要があります。MCPサーバというものがどんなものについてかは、以下の記事に楽しく かつ わかりやすく紹介されています。 面倒な仕事はMCPにやらせよう 〜AIはどこまで仕事ができるのか?〜 MCP(Model Context Protocol)は、AIと仕事の関係をどう変えるのか?架空の会社の業務シナリオを通じて、AIが複数のツールを連携させて複雑なタスクを自動化する過程を実証。具体的な設定方法や課題、未来の展望までを解説します。 blog.usize-tech.com 2025.08.20 AWS の MCP サーバの種類や設定方法などは、 AWS MCP Servers のページに詳しい記載があります(英語です)。 Welcome to AWS MCP Servers | AWS MCP Servers Get started with AWS MCP Servers and learn core features. awslabs.github.io (※10) Normalization Factor についての詳しい解説は、以下の AWS Blog “New – Instance Size Flexibility for EC2 Reserved Instances” にあります。 New – Instance Size Flexibility for EC2 Reserved Instances | Amazon Web Services Reserved Instances allow AWS customers to receive a significant discount on their EC2 usage (up to 75% when compared to ... aws.amazon.com データベースの完成 プライマリキーの問題や、データ型の問題を解決した 私と Qちゃんはいよいよデータベースを作成します。 私 (よし! これで準備は整った!)料金表CSVファイルから SQLite のデータベースを作成して! Qちゃん まかせて! … … … … … 5分くらいかかったけど、できたわ! EC2: 6,613,155行 RDS: 443,009行 Redshift: 2,580行 ElastiCache: 0行(列数不足でスキップ) ES: 0行(列数不足でスキップ) よ。 ちゃんとSQLで検索できるのも確認済みよ!(どやぁ) 私 (5分で7百万件処理したのかよ!すっげぇ! でも、スキップしちゃってるのにどや顔してるQちゃん ポンコツかわいい …じゃなくて!)え、なんで ElastiCache と ES は 0件なの? 列不足ってなに? Qちゃん 調べてみるわ… うーん、ElastiCache と ES ファイルは、EC2 や RDS と比べて列数が少ない固有の構造のようね。でも、こんなものは今までの問題と比べたら簡単よ! ちょっと直して実行してみるわね。 … … 列不足についての修正完了 … もう一度データベース作成 … 6分でできたわ! ✅ EC2 : 6,613,155行 ✅ ElastiCache: 43,125行 (解決!(※11)) ✅ ES: 39,148行 (解決!) ✅ RDS: 443,009行 ✅ Redshift: 2,580行 よ! これで解決ね! (※11)実際にQちゃんが ✅ マークとか、 (解決!)とかつけて結果報告してくれました。かわいい。 おわりに こんな感じで、チャットで会話のやり取りをしながらツールを開発していくことができます。なんとなく雰囲気を感じることができたでしょうか? 本来なら、作成された後の データベースについて、さらなる検証が必要(本当にその件数でいいの?とか、入っているデータは正しいの?など)なのですが、それはこのBlogの外で行ってると思ってください。 実際にこの作業中、私自身はコードを1行も書くことなく、Qちゃんとの会話や回答内容から Go / Stop / OK / NG と 提案しているだけで、ツールとデータベースが形になっていっています。こういう事ができるとなると、すぐに「では、ソフトウェア開発者は不要か?」ということを想像する方々もいらっしゃるかもしれません。しかし実際はそうではなく、コードはきちんとできているのか? それはどう問題がないと確認したのか? 報告してきた内容に嘘はないか? 嘘がないことをどう裏取りや検証するのか? など、プログラマの立場ではなく、プロジェクトマネージャのような立場での振る舞いを要求されていることを実体験から得ています。個人的に使うような簡単なツールなどであればともかく、信頼性の必要な業務システムにおいてはソフトウェア開発の知識や経験は依然必要であり、ソフトウェア開発者は依然として必要とされることがわかると思います。ソフトウェア開発者という立場がなくなるのはまだまだ先のようです。 と、いうわけで、最後はこの言葉で締めたいと思います。 「私とQちゃんの旅はまだまだこれからだ!」(作者の次回作にご期待ください。)
本記事は 夏休みクラウド自由研究2025 8/29付の記事です 。 こんにちは、織田です。 今回は自由研究として、 ESXi 8.0u3eをインストールして動かしてみた ので、今回実施した内容を画像付きで紹介させていただきます! 同じような取り組みをされている方の参考になれば幸いです! 思ったより長くなってしまいましたが、お付き合いいただければと思います。 概要 今回操作するのは、VMwareが提供するハイパーバイザーであるESXiの無償版です。 基本的にはESXiの利用には有料のライセンスが必要になるのですが、一部機能を制限した無償版がリリースされたとのことで今回はそちらをインストールして動作させるところまで実施します。 以下は今回使用するESXiのリリースノートになります。 VMware ESXi 8.0 Update 3e リリース ノート techdocs.broadcom.com リリースノートの内容から大まかに、以下の3つの制限がかけられていることがわかります。 Broadcomのサポートが利用できない(本番環境での使用は非推奨) vCenter Serverに接続できない 仮想マシンあたり最大8個まで仮想CPUをサポート これらの制限は本番利用を考えるとかなり厳しめですが、検証用途であれば十分色々なことを試すことができると思います。 準備 それではESXiをインストールするための準備していきます。 Broadcomサポートポータル登録 リリースノートに書かれている通り、BroadcomサポートポータルからESXiのISOファイルをダウンロードする必要があります。 初回はアカウント登録から実施する必要がありますので、ここのではアカウント登録の流れをご紹介させていただきます。 手順 ①:Broadcomサポートポータルにアクセスし、右上の「Register」を押下し、登録画面を開きます。 URL: https://support.broadcom.com/ ②:登録するメールアドレスを入力します。 ③:②で入力したメールアドレス宛に認証コードが届くので入力します。 ④:自分の名前やパスワードなどを入力し、「Create Account」を押下します。 ⑤以上で、登録が完了しました。右上の「Login」を押下してログイン画面を開いてください。 ESXiのダウンロード アカウント登録が完了しましたらいよいよESXiをダウンロードします。 手順 ①:ログイン画面では先ほど登録時に入力したメールアドレス、パスワードを入力してログインします。 ②:ログインできましたら、左の「My Downloads」を押下します。 ③:「 Free Software Downloads available HERE 」をクリックします。 ④:Free Downloadsのページが開きますので、一番下までスクロールします。 ⑤:下までスクロールすると「VMware vSphere Hypervisor」があるので、押下します。 ⑥:再度「VMware vSphere Hypervisor」を押下します。 ⑦:「I agree to the Terms and Conditions」のリンクを押下して内容を確認後、チェックボックスにチェックを入れ、右側のダウンロードボタンを押下し、ESXiのISOファイルをダウンロードします。 以上で、ISOのダウンロードは完了です。 ダウンロードする際に住所情報などの入力を求められる場合があります。 (余談)ESXiインストール環境の準備 今回ダウンロードしたESXiはISOファイルですので、インストールメディアを作成して実際のPCにインストールすることができます。 ただ、自分の環境では自由にOSを消せるPCがなかったため、今回はProxmoxという別のハイパーバイザーに仮想マシンという形でインストールすることにします。 同じようにESXiを仮想マシンとしてインストールされる方がいらっしゃいましたら、仮想化ツールごとにESXiインストール用仮想マシンの作成方法に注意点があると思いますので、いろいろ調べて類似作業をされている事例などを探してみてください。 手順 ①:Nodeを選択し、Nameに今回作成する仮想マシン名を入力します。 今回は一番容量の多いものをNodeで選択し、そのNode名に関連づけるように仮想マシン名をNameに入力しました。 ②:先ほどダウンロードしたISOファイルをISO imageで選択します。 ※この手順実施前にProxmoxにISOをアップロードを実施していましたが今回は割愛させていただきます。 詳細な手順が気になる方は「Proxmox ISOアップロード」などで検索してみてください。 ③:ここはデフォルトのまま次に進みます。 ④:Bus/Deviceで「SATA」を選択します。 ここでSATAを選択しないとESXiインストール時にインストール可能なストレージとして認識されなくなるので、ご注意ください。 ディスクサイズはお好みで決めて問題ないです。あまり小さすぎると正常に動作しない恐れがあるのでご注意ください。 今回は256GBとしています。 ⑤:Typeで「host」を選択します。 hostを選択しないとESXiのインストーラーが起動しないのでご注意ください。 コア数はお好みで決めて問題ないです。あまり小さすぎると正常に動作しない恐れがあるのでご注意ください。 今回は4コアにしています。 ⑥:メモリサイズはお好みで決めて問題ないです。 あまり小さすぎると正常に動作しない恐れがあるのでご注意ください。 今回は16GBとしています。 ⑦:Modelは「VMware vmxnet3」を選択します。 ここで変更しないとインストール後、ESXiへネットワーク経由でアクセスできなくなる恐れがあります。 ⑧:ここまでの設定内容を確認して、問題なければFinishを押下し、仮想マシンを作成します。 ESXiを使ってみる 先ほど作成した仮想マシンにESXiをインストールします。 ESXiインストール 手順 ①:Proxmoxの画面から作成した仮想マシンを起動するため、Start Nowを押下します。 ②:起動するまで待ちます。 ③:Installerを選択した状態でEnterを押下します。 ④:Enterを押して次に進みます。 ⑤:EULAが表示されるので、内容を確認してF11を押下し、次に進みます。 ⑥:インストール先のストレージを選択します。今回は一つしかないので、そのままEnterを押下して次に進みます。 ⑦:キーボードレイアウトを選択します。今回は日本語配列を選択しています。 ⑧:パスワードを入力します。 ⑨:ここで一部警告が出ることがあります。今回はFirmwareがUEFIでないことについて警告が表示されています。 ⑩:インストール先のストレージのデータが消えることの警告が出ます。問題なければF11を押下しインストールを実施します。 ⑪:インストールが完了するまで待ちます。 ⑫:インストールが完了しました。Enterを押下して再起動します。 ⑬:再起動が完了するまで待ちます。 ⑭:インストールが完了すると、グレーと黄色の画面が表示されます。 黄色の部分に表示されているIPアドレスにブラウザでアクセスするとHost Clientに接続できます。 初期設定など DCUIを使用していくつか設定を入れます。 手順(Host Clientにログインし、ライセンスを確認するまで) ①:今回はDHCPでIPアドレスに192.168.0.14が設定されているので、ブラウザに入力してHost Clientにアクセスします。 ②:ユーザー名はroot、パスワードはインストール時に設定したパスワードでログインすると、画像のような表示が出ます。 カスタマーエクスペリエンス向上プログラムへの参加が問われているので、お好みでチェックボックスを外す/残すなどしてください。 ③:以下の通り、ログイン後ライセンスが確認できました。 ライセンスは無償版用のライセンスが初めから適用されています。念のためマスキングしています。 失効日はNeverとなっています。 以上でHost Clientにアクセスできることがわかりましたので、次にDCUIからホストの設定変更などを実施します。 手順(DCUIからホスト名などを変更) ①:インストールが完了した画面でF2を押下すると、以下の通りログイン画面が出てきます。 インストール時に登録したパスワードを入力し、Enterを押下するとログインできます。 ③:ログインするとSystem Customization画面が表示されます。 ④:Configure Management Networkにカーソルを移動させ、Enterを押下すると以下の画像のような画面に遷移します。 ⑤:今回はDNS Configurationにてホスト名を設定してみます。 ⑥:画面右側で現在の設定値を確認することができます。Hostnameに先ほど設定した値が入っています。 ⑦:Escを押下すると設定を保存するかを問う画面が表示されます。Yを押下し保存します。 今回はネットワークの設定でホスト名を変更するだけでしたが、IPv4 Congfigurationなどを選択するとESXiのIPを変更できます。 ⑧:続きまして、Troubleshooting Optionsを選択します。 ⑨:ESXi ShellとSSHを有効化する項目があります。 ⑩:ESXi ShellとSSHをそれぞれ有効化します。 以上で初期設定は完了です。 VM作成準備 ESXiインストールと初期設定が完了したので、V実際にVMを作成してみたいと思います。 が、その前に一つ準備が必要です。 準備内容はVMにインストールするOSのISOファイルのアップロードです。 今回は個人的に使い慣れているUbuntu Desktopをアップロードしておきます。 手順 ①:データストアブラウザ画面を開きます。 ②:datastore1を選択した状態で、「Create directory」を選択し、ISOファイル格納用に「ISO」という名前のDirectoryを作成します。 ※datastore1はESXiインストール時の余ったストレージ領域を使用して自動で作成されるデータストアです。 本番環境では使用が推奨されませんが、今回は検証なのでこちらを使用します。 ③:datastore1の内部にISOディレクトリが作成されました。 ④:ISOディレクトリを選択した状態で、「Upload」を選択し、アップロードするファイルを選択します。 ⑤:アップロードが完了すると、画像の通りISOファイルが見えるようになります。 以上でVM作成の準備が完了しました。 ESXi上でのVM作成 アップロードしたISOファイルを使用して、ESXiでVMを作成します。 手順 ①:「Create / Register VM」を選択します。 ②:「Create a new virtual machine」を選択し「Next」を押下します。 ③:「Guest OS family」で「Linux」を選択し、「Geust OS version」で「Ubuntu Linux(64bit)」を選択し、「Next」を押下します。 ④:インストール先のデータストアを選択します。 今回はdatastore1しかないので、そのまま「Next」を押下します。 ⑤:割り当てるリソースを変更します。 今回はCPUを2に、Memoryを8GBにします。 割り当てるリソースが少なすぎると正常に起動しない恐れがあります。 ⑥:CD/DVD DriveでDatastore ISO filesを選択します。 ⑦:データストアブラウザが開くので、先ほどアップロードしたISOファイルを選択し、SELECTを押下します。 ⑧:選択したISOファイルがCD/DVD Driveに記載されていることを確認し、Nextを押下します。 ⑨:最後にここまでの設定が正しく行われているかを確認しFINISHを押下ます。 ⑩:以上で仮想マシンが作成されました。 ⑪:仮想マシンを選択すると詳細画面が開きます。Power Onで仮想マシンを起動します。 ⑫:ConsoleからOpen browser consoleを選択します。 Ubuntuインストール on ESXi VMの作成が完了したので、OSのインストールを実施します。 Ubuntuのインストール手順の話が続きますので、参考程度に見ていただければと思います。 手順 ①:Consoleが起動するとUbuntuのインストール画面が表示されます。 インストールするため、Try or Install Ubuntuを選択します。 ②:インストーラーが起動するまで待ちます。 ③:デフォルトのままNextを押下します。 ④:デフォルトのままNextを押下します。 ⑤:Japaneseを選択しNextを押下します。 ⑥:デフォルトのままNextを押下します。 ⑦:デフォルトのままNextを押下します。 ⑧:デフォルトのままNextを押下します。 ⑨:デフォルトのままNextを押下します。 ⑩:デフォルトのままNextを押下します。 ⑪:デフォルトのままNextを押下します。 ⑫:ユーザー名、パスワードなどを入力します。 ⑬:デフォルトのままNextを押下します。 ⑭:Installを押下します。 ⑮:インストールが完了すると以下の画面が表示されます。 Restart nowを選択すると再起動が開始されます。 ⑯:再起動が完了すると以下の画面が表示されるので、Enterを押下します。 ⑰:再起動が完了するとログイン画面が表示されます。 インストール中に設定したパスワードを入力しログインします。 ⑱:ログインするとWelcomeのポップアップが表示されます。 特に設定などはせずにNextを押下してポップアップを閉じます。 Ubuntu操作 OSのインストールが完了し操作が可能になったので、少し操作してみます。 手順 ①:ツールバーからターミナルを開きます。 ②:ipアドレスを確認してみます。 今回はVM作成時にデフォルトから変更していないので、ESXiのセグメントでIPアドレスが振られています。 ③:apt updateを実行してみます。無事実行できたのでインターネットへの通信は問題ないことがわかります。 ④:htopをインストールします。 ⑤:htopを実行してみました。2コア8GBメモリが割り当てられていることがわかります。 ⑥:ESXiにてSSHを有効化したので、仮想マシンからESXiへSSH接続を試してみます。 ⑦:ESXiのパスワード入力し、無事ログインできました。 ⑧:コマンドを試しに実行してみます。 「vmware -l」を実行し、ESXiのバージョンが正しく取得できていることがわかりました。 ⑨:現在ESXi上で稼働している仮想マシン情報も取得してみます。 test-vmが動作していることが正しく取得できました。 最後に 今回は無償版ESXiのダウンロードからインストール、その後のVM作成などまで一通り試してみました。 今後は今回インストールしたESXiなどを活用した検証記事などを出していきたいと思います。 今回説明しきれなかったことなども、追々説明できればと思います。 想定よりだいぶ長くなってしまいましたが、最後までお付き合いいただきありがとうございました!
本記事は 夏休みクラウド自由研究2025 8/28付の記事です 。 皆さんこんにちは。 好きな百人一首は柿本人麿3番。いとさんです。 もう夏休みも佳境に入りました。早いものですね。 今回は自由研究という事でAmazon Q CLIを使ってAWSサービス百人一首(正確には324人)を作ってみました。 きっかけ 先日参加させていただいたAWS Buildercards勉強会でとても楽しかったのですが経験者や学習中向けのゲームだなと感じ、日本人超初心者向けのカードゲームを作れないかと考え今回の作成に至りました。 ゲームの概要 今回作るのはAWSサービスの概要を短歌にした百人一首形式のAWSカードゲームです。 初学者はサービスを学べ、上級者はより多くのサービスを覚えることが出来る内容になっています。 今回使用したツール AmazonQ、Web speach APIの二つを使用しています。 今回のゲームはローカル上に以下のファイルを作成し、AWSアカウントを持っていない人でも遊ぶことができます。 Amazon Qに渡したプロンプト 日本の百人一首をモチーフにした読み札が上の句、下の句で分かれている本格的な百人一首ゲームを作成してください 実装する主要機能 動作環境 ブラウザ ゲーム難易度 簡単 動作生成 ・日本の百人一首をモチーフに ・読み札は5・7・5・7・7、日本の短歌の音数律で作成 ・お手つきしたら1回休み ・難易度は簡単、普通、難しいの三種類 敵キャラクター ・敵キャラクターはAWSの画像生成機能で作成で表現してください。 操作方法 マウス: 取り札取得 マウス/タッチ: 画面のボタンで全操作可能 ゲームの特徴 1.完全ランダム生成: 毎回新しい取り札、読み札レイアウト 2.成長システム: レベルアップでキャラクター強化 3.戦略性: 手札は暗記で覚えられるがふだが多いので暗記の難易度が高い 4.視覚的: 絵文字による分かりやすい表現 5.無限プレイ: 高いレベルに進むほど難易度大幅アップ 今回プロンプトで工夫した点は音数律という短歌ならではの単語を入れた事と、ランダム性のある取り札指定です。 AIがどこまで理解して作ってくれるのでしょうか。 完成したver1 おお‥色味が独特ですね。もう少し古風にしたいところです。 AWSという単語は入れましたがAWS百人一首とは打ち込まなかったのでただの百人一首ゲームになってしまいました。 他にも音声が流れない、札が読み終わるまで取れない、取り札がインベントリになっているなど修正部分が多くありそうです Amazon Qの動きを確認 以下修正プロンプト結果を抜粋して記載いたします。 上記含め合計 57回 の修正を行いました。 二つ目の画像内でBeadRock使用というプロンプトがありますが 公式アイコンをローカルから読み込むように変更したので結果的には使用しておりません。 今回作成されたファイル 🎮 必須ファイル(4個) index.html – メインHTML style.css – スタイルシート game.js – ゲームロジック hyakunin-isshu.js – 古典百人一首データ ☁️ AWS機能用(3個) all-aws-services-manual.js – AWS百人一首(400首) service-descriptions.js – サービス解説 aws-icon-mapper.js – アイコンマッピング このファイル選定もAmazon Q CLIにプロンプトを投げて教えてもらいました(とても便利) 作成されたゲーム 緑基調の古風な色味の指定やボックス、画面遷移などをQに投げプロンプト通りに設定してくれました。 反応も問題なく、正解時は上記のようなポップアップウィンドウが表示され、間違っている時にはお手つきと下に表示されます。 まとめ Amazon Q CLIは原因調査、コーディング修正が早くとても素早く作る事が出来ました。 この良さを生かしAWSでの環境構築の目的を打ち込み必要な関数、手順を素早く提示してくれるかもできないかという淡い期待を持って今後調査していこうと思います。 今回短歌もAmazon Q CLIに作成してもらいましたが口語ではなく文語の57577になってしまった独創性という点では人が作った方が面白いかも知れないと感じました。 デザインに関してグラデーションを多用する一面やフォントの独創性があるように感じた。カラーコードを事前に渡していれば解消するかも知れないですね。 短歌募集! ということで、 AWS短歌募集します!! 皆さんの好きなサービスの短歌を作って最高に面白い324人1首を完成させましょう!🎴 フォームはこちらから Microsoft Forms forms.office.com 完成したゲームのソースコード GitHubでソースコード公開しておりますので是非ダウンロードして楽しんでください!(短歌は随時更新予定です🎴) AWSアカウントお持ちの方はS3に保存してCloudFront使用すると携帯でも遊ぶことが出来ます。 GitHub - rourouAI/AWS-100nin1syu: AWSサービスを学べるカルタです AWSサービスを学べるカルタです. Contribute to rourouAI/AWS-100nin1syu development by creating an account on GitHub. github.com
こんにちは、SCSKの前田です。 私が携わった LifeKeeper の案件で導入を行った ARK について紹介をかねてお話したいと思います。 今回は、MySQL編と言うことで、世界で広く利用されているリレーショナルデータベース管理システムとなるMySQLを簡単に冗長化するための ARK の導入事例について、ご紹介していきます。 おさらい LifeKeeperのARKについて、おさらいしたいと思います。 ARK とは、Application Recovery Kits の略で、LifeKeeper が特定のアプリケーション(オープンソースソフトウェアや商用アプリケーション)を容易にリソースとして組み込むことが可能になる製品です。 ARK による、アプリケーションのリソースへの組み込みはウィザード形式(GUI上で設定)で作業が可能となり、ARK には、アプリケーションを操作(起動・停止・監視・再起動)するための4つのスクリプトがあらかじめ準備されているため、スクリプトを設計・作成するための開発工数の削減や人的なミスを防止することが出来ます。 概要説明 MySQL ARK では、MySQL を保護対象リソースとして登録し、保護する機能を提供します。 MySQL ARK では、複数の MySQL インスタンスを稼働させることが可能になっています。 複数の MySQL インスタンスを稼働させる時の考慮事項は以下通りになります。 複数の MySQL インスタンスを稼働に関する考慮事項 ・複数の(同一もしくは異なるバージョンの) MySQL インスタンスを稼動させる場合、可能であれば mysqld グループの機能を使用することを考慮してください。MySQL ARK では、複数の MySQL インスタンス構成に対して mysqld グループ (mysqld_multi) を使用することが推奨されています。 ・複数の MySQL インスタンスを稼働させる場合、共有ファイルシステムを /var/lib/mysql としてマウントしないでください。mysql 起動コマンド (safe_mysqld or mysqld_safe)により、MySQL サーバが予期せずシャットダウンされるためです。 ・mysqld グループの機能を使用しない場合、 my.cnf ファイルは、各ノードのデータディレクトリに保存する必要があります。mysqld グループを使用する構成では、 my.cnf ファイルはデータディレクトリではなく /etc に保存してください。 ・MySQL 用の追加のポート番号は、 /etc/services ファイルに指定する必要があります。 ・各 MySQL インスタンスは、個別のポート上で稼働し、個別のソケットファイルにアクセスするように設定する必要があります。これらの設定オプションは、データディレクトリにある my.cnf ファイル内で指定してください。 ・各ノードは、個別の共有の位置からデータにアクセスするように設定する必要があります(つまり、各サーバは個別のデータディレクトリを使用する必要があります)。 MySQL ARK は、汎用アプリケーション(Generic Application)リソースの導入とは違い、起動・停止・監視・再起動を行うためのスクリプトを明示的に指定することはなく、リソースの作成に必要な項目に対するパラメータをウィザード形式で入力または、選択することでリソースを作成することが出来ます。 MySQL ARK として MySQL の処理内容は以下の通りとなります。 MySQL の処理 処理名 処理内容 起動処理 ①監視処理と同一の処理を実施し、MySQL が停止状態であることを確認 ② ①で MySQL が停止状態である場合、safe_mysqld または mysqld_safe または systemctl コマンドにより MySQL インスタンスの起動を実施 ③ ②を実行後に 5秒待機し、監視処理と同一の処理を実施し、MySQL が稼働状態であることを確認(指定された回数分繰り返し確認を実施) ④ ③で MySQL の稼働状態が確認出来ない場合、②と③の処理を実施(稼働状態であると判断されるまで再試行の回数分繰り返す) ⑤ ④で MySQL の稼働状態が確認出来ない場合、safe_mysqld または mysqld_safe コマンドにより MySQL インスタンスの強制起動を実施 (systemd 環境の場合は、MySQL の強制起動処理は無く、⑥に進む) ⑥ ⑤を実行後に、監視処理と同一の処理を実施し、MySQL が稼働状態であることを最終確認(指定された回数分繰り返し確認を実施) ⑦ ⑥で MySQL の稼働状態が確認出来ない場合、起動処理は失敗となる 停止処理 ①監視処理と同一の処理を実施し、MySQL が稼働状態であることを確認 ②mysqladmin コマンドにより MySQL インスタンスの停止を実施 ③ ②で mysqladmin コマンドが成功と判断されない場合、PS コマンドにより MySQL インスタンスのプロセスの確認を実施 ④ ③で MySQL インスタンスのプロセスが確認された場合、親プロセスに対し SIGTERM を発行し、5秒 (固定)待機 ⑤ ④で親プロセスが停止しない場合、親プロセスに対し SIGKILL を発行し、5秒 (固定)待機(指定された回数分繰り返し SIGKILL の発行を実施) ⑥ ⑤で親プロセスが停止しない場合、③で確認した MySQL インスタンスのプロセスに対し SIGTERM を発行し、5秒 (固定) 待機 ⑦ ⑥でプロセスが停止しない場合、停止処理は失敗となる 監視処理 ①mysqladmin コマンドにより VARIABLES 変数の確認を実施(VARIABLES 変数が参照出来た場合、稼働状態と判断) ② ①で VARIABLES 変数が参照出来ず、MySQL の「PID ファイル」が存在する場合、ps コマンドにより「PID ファイル」に記載された番号のプロセスが存在するか確認を実施 MySQL の「PID ファイル」が存在しない場合、ps コマンドにより指定の「ポート番号」と「ソケット」を使用するプロセスが存在するか確認を実施 (プロセスの存在が確認出来た場合、稼働状態と判断) 再起動処理 停止処理と起動処理を順に実施 MySQL ARK の構築例 それでは、実際に MySQL ARK の構築についてお話していきたいと思います。 まずは、MySQL のリソース作成時に設定する特有のパラメータを一覧表にまとめましたので紹介いたします。 MySQL ARK のパラメータ項目 項目 説明 my.cnf のディレクトリーパス MySQL 設定ファイル (my.cnf) が存在する場所のフルパス名 (ファイル名は除く) を選択または入力 MySQL 実行パス MySQL データベースサーバデーモンの開始と監視に使用されるバイナリーのフルパス名選択または入力 SQL Server リソースの作成 MySQL リソースを LifeKeeper の GUI によって作成する流れを例として紹介します。 処理内容 GUI画面例 リソース作成前のツリー構造 対象のプライマリサーバー 及び Appllication Recovery Kit の選択(My SQL Database) my.cnfのディレクトリーパス 及び MySQL実行パス の選択または入力 MySQLリソースタグ 及び スイッチバックタイプ の選択または入力 稼働系ノードでの MySQLリソース の設定内容確認 稼働系ノードでのリソース作成結果 ターゲットサーバー 及び プライオリティ の選択または入力 待機系ノードのリソース作成準備の確認結果 待機系ノードの スイッチバック の選択 待機系ノードでの MySQLリソース の設定内容確認 待機系ノードでのリソース作成結果 リソース作成後のツリー構造 これで、LifeKeeper による MySQL のリソースが完成です。 まとめ 今回は LifeKeeper ARK の導入事例と言うことで、MySQL のリソース作成について紹介してみました。 MySQL ARK は、汎用アプリケーション(Generic Application)リソースとは違い、起動・停止・監視・再起動を行うためのスクリプトを準備する必要がなく、リソースを作成することで意識することなく自動でスクリプトが導入されます。 MySQL ARK では、複数の MySQLインスタンス が稼働させる環境にも対応しています。※「複数の MySQL インスタンスを稼働に関する考慮事項」を参照。 MySQL ARK を導入するための手順を纏めます。 ・MySQL のリソース固有のパラメータの設定値を検討する ・LifeKeeper GUI を用いて、MySQL のリソースを作成する LifeKeeper では MySQL 以外にも多数の ARK が用意されていますので、また次の機会に別の ARK について紹介していきたいと思います。 その他 ARK の導入事例に関しては以下のリンクからどうぞ! LifeKeeper ARK の導入事例を紹介<JP1/AJS3編> – TechHarmony LifeKeeper ARK の導入事例を紹介<Oracle編> – TechHarmony LifeKeeper ARK の導入事例を紹介<SQL Server編> – TechHarmony LifeKeeper ARK の導入事例を紹介<NFS/HULFT 編> – TechHarmony 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで
こんにちは。SCSKの山口です。 今回はBigQuery Editionsの料金体系についてのブログです。 これまでのオンデマンド課金やフラットレート課金と何が違うのか、そしてどのように活用すれば良いのか解説します。 BigQueryの従来の課金体系 BigQueryの分析料金には、主に2つの課金体系がありました。それぞれの特徴を簡単に見てみましょう。 1. オンデマンド課金(従量課金) クエリがスキャンしたデータ量に応じて課金されます。料金は1TBあたり $6.25 (東京リージョン)が目安です。 メリット: 使った分だけ支払うので、利用頻度が低い場合に効果的 事前のキャパシティ予約が不要 デメリット: データスキャン量が増えると、費用が急増する可能性 クエリごとに料金が発生するため、コスト予測が難しい場合がある 2. フラットレート課金(キャパシティ課金) 月額固定料金で スロット(クエリ処理能力) を借り切る形式です。定額制なので、コストを予測しやすいのが特徴です。 メリット: 大量のデータ分析を行う場合、オンデマンドよりも安価になる可能性がある コスト予測が非常に立てやすい デメリット: 利用が少ない月でも固定費用が発生 最低契約期間がある BigQuery Editionsとは? BigQuery Editionsは、これまでのフラットレート課金に代わって、より柔軟な料金体系を提供するために導入されました。 3つのエディションがあり、それぞれ異なるスロットのコミットメントレベルと料金設定がされています。 3つのエディション Standard Edition: 低頻度なワークロードや、開発環境・テスト環境向け。 Enterprise Edition: ほとんどのエンタープライズ向けワークロードに適しており、高度なセキュリティ機能や管理機能が利用可能。 Enterprise Plus Edition: 非常に要求の厳しいワークロード向けで、最高レベルのセキュリティ、コンプライアンス、信頼性を提供。 オンデマンド課金との違い 最も大きな違いは、 「スロットの予約」 と 「料金体系」 にあります。 オンデマンドはデータスキャン量に基づく従量課金ですが、Editionsは 「分単位」または「秒単位」 での スロットの消費量 に基づきます。 比較表 特徴 オンデマンド BigQuery Editions 料金単位 スキャンしたデータ量(TB) 利用したスロット数(秒または分) コスト予測 難しい 比較的容易 スロット予約 不要 必要(分単位、月単位など) 用途 利用頻度が低い、開発・検証 本番環境、大規模な分析 💡 重要なポイント: オンデマンド課金は「使ったデータの量」で支払うのに対し、Editionsは 「確保した計算能力の時間」 で支払います。これにより、大量のデータ分析を頻繁に行うユーザーは、コストを大幅に削減できる可能性があります。 BigQuery分析料金の課金体系フローチャート ここまでの説明を踏まえて、BigQueryの分析料金の課金体系を決めるには、いくつかの判断ポイントがあります。 カンタンなフローチャートにまとめると下記のようになります。 上図を見てもわかる通り、「BigQuery Editionsを使おう」となってもその先にまた判断ポイントがあります。 BigQuery Editionsを「従量課金」で利用するか「コミットメントを購入する」か です。(実は併用も可能ですが、詳細は後ほど説明します。) BigQuery Editionsを従量課金で使用する 従量課金で利用する場合は、下記の設定値が重要になります。 ベースライン(Baseline) ワークロードがアイドル時にオートスケーラーが維持する処理能力の量 特定のワークロードに対して 最低限の処理能力を確保 したい場合に設定 最大スロット(MAX) ワークロードがピーク時のパフォーマンスを達成するためにオートスケーラーが使用できる処理能力の量 予期せぬクエリの急増によるコストの急騰を防ぐ ために設定 最大スロット以上が要求されると、ジョブがスロットの空き待ちになる 以下のようなイメージです。 ベースラインのスロット数までは固定料金として支払いますが、ベースラインから最大スロット数までのは従量課金として支払うイメージです。 BigQuery Editionsでコミットメントを購入する さらに、BigQuery Editionsには「コミットメント購入」という利用方法もあります。 カンタンにいうと、クエリ実行に必要な計算能力(スロット)を、長期的に確保することで割引を受ける仕組みです。 スロットの事前購入 : BigQueryのコンソールから、1年間または3年間の期間で、一定のスロット数(最小100スロット)をまとめて購入 割引の適用 : 長期間の利用を確約する代わりに、オンデマンド課金や時間単位のコミットメントよりも大幅に安い単価でスロットを利用 柔軟な運用 : 購入したスロットは「予約」として管理され、特定のプロジェクトや組織に割り当てて利用 オートスケーリング : 予約したスロットを超えてクエリ実行にスロットが必要になった場合、自動的に追加のスロットが提供され、その分はオンデマンド課金となります。この柔軟性により、コストを抑えつつ、急なワークロードの増加にも対応可能 以下のようなイメージです。 常時多くのスロットを消費しているようなワークロードに対して、スロットをまとめて購入します。 ただし、上図は 極端な例 です。 オンデマンド課金で利用している状態から、いきなり上図にシフトするのはまれなケースだと思います。 BigQuery Editionsで従量課金とコミットメントを併用する 先述した通り、従量課金とコミットメントは併用することが可能です。 例えば、「BigQuery Editionsを従量課金で使用していたが、扱うデータ量/連携先が増え、ワークロードが増加した」場合を考えてみましょう。以下の図のようなイメージです。 設定したベースラインがもはや意味を成していないように見えますね。 上図のような際、ベースラインを引き上げるのももちろん手ですが、長期的に見てもこのような状態が続くのであれば、 一部コミットメントを購入する といった合わせ技が可能です、 オンデマンド課金からEditionsへ移行する際のおすすめフロー オンデマンド課金からEditionsへの移行にあたって、私が考えるおすすめステップは下記です。 Step 0: 現在の利用状況を把握してBigQuery Editionsを使用するか判断 まず、過去のクエリ履歴とコストを分析します。 INFORMATION_SCHEMA.JOBS ビューを利用して、クエリのスキャンデータ量やスロット消費量、実行時間を計測 BigQueryの 「料金」 ページや 「Cloud Billing」 レポートで、過去のコスト推移をチェック このデータから、日・週・月ごとの平均的なスロット使用量を割り出します。 割り出したデータから、「ワークロードの実行に偏りがあるか」「一定期間、まとまったスロット使用量が使用されていないか」などを確認し、BigQuery Editionsを使用するか判断します。 Step 1: BigQuery Editionsを「従量課金」で使用する BigQuery Editionsを使用するとなった場合、まずは「従量課金」で使用されることをお勧めします。 前述したとおり、ベースラインと最大スロットの設定が必要になります。 中でも 最大スロット数の見積もり には注意が必要です。 最大スロット以上の容量が要求されると、ワークロードのジョブが スロットの空き待ち となってしまうためです。 パフォーマンス要件が厳しいワークロードの際は特に注意が必要です。 BigQuery Editionsの使用を開始することで、BigQueryの「容量管理」から スロットの使用状況 などの情報を確認できるようになります。 確認方法については下記ドキュメントをご参照ください。 https://cloud.google.com/bigquery/docs/slot-estimator?hl=ja Step 2: コミットメントの購入を検討する Step1で収集した情報をもとに、 コミットメントの購入 を検討します。 いきなり使用スロットをすべてコミットメントで購入するか、一部をコミットメントとして購入するか。の判断が必要になりますが、前述したとおり、いきなりすべてをコミットメントで購入するパターンは稀だと思います。 まとめ 今回のブログで解説したように、BigQuery Editionsに移行する際は、まずは現在のスロット利用状況を正確に把握し、そこから最適なコミットメントのレベルを見極めることが成功の鍵です。BigQuery Editionsの機能を最大限に活用し、コストを抑えながらビジネスの成長を加速させましょう。 BigQuery Editionsをあなたのワークロードにどう活かしていくか、ぜひ検討してみてください。
本記事は 夏休みクラウド自由研究2025 8/27付の記事です 。 こんにちは、SCSKでAWSの内製化支援『 テクニカルエスコートサービス 』を担当している貝塚です。 5か月ほど前(もうそんな昔になるのですね…)、AWS Transit Gateway・AWS Direct Connect経由でオンプレミス環境と接続しているVPCの検証に関する記事を書きました。 AWSのVPC間でAWS Site-to-Site VPNを構成する 今回は、テクニカルエスコートサービスによくご相談いただくDirect Connectまわりのご質問について解説します。 よくあるご相談:オンプレミスから既存とは別のVPCにつなぎたい 過去にオンプレミス環境からAWS上に構築したシステムに接続する要件があり、下図のようにvGW(仮想プライベートゲートウェイ)をDirect Connectにアタッチする形でVPCと接続しているケースがよくあります。 そして、AWSの利用が進み、別のVPCに構築したシステムをオンプレミス環境と接続したい(下図)。どのような構成にすればよいか?というご質問をよく頂きます。 構成案:VPC間をVPC Peeringで接続する ご相談いただく際、ご相談者から、以下の案の実現性を訊かれることがあります。 この構成ですが、オンプレミスとVPC2は通信ができません。 VPC間の接続について調べたことがある方であれば推移的ピアリング(はできない)という制約について聞いたことがあるかと思います。VPC A, B, CがあってA – B, A – C をVPCピアリングの機能で接続したときに、A経由でB←→Cの通信はできないというものです。 vGWもVPCピアリングに似た性質を持っているため、前の図のVPC2 ←→ オンプレミスの通信はできないのです。 「vGWもVPCピアリングに似た性質を持っている」という点についてですが、IPルーティングの基礎的な知識をお持ちであれば、以下のように考えると理解しやすいかと思います。 VPCピアリングは、VPCとVPCの間に仮想的なVPCピアリング用ルータがあると考えることができます。(ユーザは確認することができませんが)この仮想VPCピアリング用ルータは、直接接続しているVPCのCIDRへの経路しか登録されていません。したがって、図で言うオンプレミス環境への経路を持っていないため、VPC2からオンプレミス環境へ向けた通信は仮想VPCピアリング用ルータで破棄されます。 vGWは、オンプレミス側からBGPで経路を受け取れるなど、仮想VPCピアリング用ルータよりも柔軟な経路設定ができるという違いはあるものの、他のVPC(この例ではVPC2)のCIDRへの経路を登録する方法がありません。このため、オンプレミス環境からVPC2へ向けた通信はvGWで破棄されます。 上記の通りVPCピアリング案は(そのままでは)うまくいかないため、正攻法として私がまず相談者の方にお話しするのは以下の2パターンです。 Direct Connect Gateway導入 Direct ConnectとvGWの間にDirect Connect Gateway (DXGW)をはさむようにします。DXGWはvGWを20個までアタッチできますので、この構成でオンプレミス環境と20個までのVPCの接続を実現できます。DXGWは料金無料ですので、利用料も上がりません。 設定次第ではあるのですが、注意点として、基本的にはオンプレミス←→VPC通信用であり、VPC間の通信はできないことが挙げられます。 Direct Connect Gateway + Transit Gateway導入 Direct Connect – Direct Connect Gateway – Transit Gateway – VPC という形で構成します。接続可能なVPCの数がDXGWよりずっと大きく(5,000 ※1)、VPC間通信も問題なく行えるため、自由度の高いネットワークを作るのであればお勧めの構成です。ただし、接続するVPC 1つごとに接続料金(50USD/1VPCくらい)が発生します。 ※1 正確には、Transit Gateway あたりのアタッチメント数が5,000 2案の実現性について 上記どちらのパターンでも、一度vGWにアタッチしたDirect Connectの仮想インターフェイスは取り外す(デタッチして別のリソースにアタッチしなおす)ことができず、削除しかできないため、多くの場合(※2)、Direct Connectを提供している通信事業者に依頼して新しい仮想インターフェイスを作成してもらい、既存の仮想インターフェイスから切り替える形になります。 ※2 Direct Connectの提供形態によります。 上記2案は、複数のVPCをオンプレミスと接続する場合にAWS公式ドキュメントなどを調べればすぐに発見できる構成案であり、拡張性や運用性の観点から優れた構成です。しかし、このようなご相談を頂くケースは、オンプレミスとの通信要件の発生したシステムの構築プロジェクトの中でネットワークの検討もしていることが多いため、そのシステムの管理・責任範囲とは言い難い(共用リソースである)Direct Connect GatewayやTransit Gatewayの新規導入や、予期していなかった通信事業者との調整などは高いハードルとなり、これら2案がすんなり受け入れられることはまずありません。 VPCピアリングとNATを組み合わせる Direct Connectまわりは触りたくないという話になると、NATを組み合わせて解決を図ることになります。下図が解決策の一例です。 オンプレミスから見るとVPC2ではなくVPC1と、VPC2から見るとオンプレミスではなくVPC1と、それぞれ通信しているように見えるようにVPC1でNAT(双方向NAT)をしてあげます。この構成であれば宛先への経路がないというルートテーブルの問題を解決できることがお分かり頂けるかと思います。 通信要件が片方向であれば、Network Load Balancer (NLB)を入れるのが簡単です。デフォルトの設定で実質的に双方向NATが実現できます。通信要件が増えるたびにNLBを増やす必要があるので、数が増えると運用管理上の問題が出てきますが、通信要件が少ないうちは手軽で負荷の少ない解決策と言えます。 双方向NATできるものであればなんでもよいので、EC2でNAT用のインスタンスを構築するのも一案です。ENIに複数のIPアドレスを割り当ててやれば、NLBのように通信要件増加ごとにEC2インスタンスを増やさなくてもよいというメリットがあります。ただし、 ENIに割り当てられるIPアドレス数上限 はさほど多くない(m5.largeで10、t3.smallで4)ため、EC2はマネージドサービスではなくユーザーの運用負荷が大きいことも踏まえると、私見ではNLBに軍配が上がると考えています。 なお、NAT Gatewayでも実現できないか?と考えたくなるところですが、あて先NAT機能を持っていないため本ケースでは不適格となります。 まとめ 普通に何らかのシステム用のリソースが置かれているVPC1上に、突如、VPC2へ通信を中継するためのリソースを配置することになるわけで、ネットワーク設計上きれいな設計とは言い難いですが、通信要件がさらに増えたときにはDirect Connect Gateway導入またはDirect Connect Gateway + Transit Gateway導入した方がよいという助言をしつつ、双方向NAT(NLB)+VPCピアリングとするのが落としどころでしょうか。もしもっと良い案ありましたら教えてください!
本記事は 夏休みクラウド自由研究2025 8/26付の記事です 。 こんにちは。辻です。 先月、表題のAWS認定資格 Cloud Practitioner (CLF-C02) に合格しましたので、今回の自由研究として合格体験記を掲載致します。 はじめに 先日、AWS CLF-C02(クラウドプラクティショナー)を受験して合格しました。 出題形式 選択問題・CBT方式 出題数 65問 試験時間 90分 合格点 700点以上 受験料 16,500円(税込/2025年8月時点) 受験場所 テストセンター 合格点は700点以上なので、ギリギリ合格できました。AWS認定試験では、試験問題の配点率は公開していないので、実際に65問のうち、どれくらい正答していてこの得点に至ったかは不明です。 受験動機 私立文系大学を卒業してから、社会人歴は9年目となりました。 数年前に全くの未経験ながらAWSのPJに短期で携わっていた時に、AWS認定資格の中級レベルであるSAA(ソリューションアーキテクトアソシエイト)を受験した経験があります。当時は、残念ながら合格できませんでした。 それからしばらく、AWSから離れた業務をしており、今年の4月から再びAWSに携わることになったので、基礎からしっかり学んでみよう!と一念発起して、受験に至りました。 使用した教材 使用したテキストは、株式会社impressから出版されている『基礎から実戦レベルまでよくわかる 元祖黒本「徹底攻略」教科書ソリューションアーキテクトアソシエイト』です。 CLF合格後にはSAAを受験する予定なので、教科書として使用するテキストはSAAのものを購入しました。 学習のために使用したサイトは下記の通りです。 ・AWS Skilll Builder ・AWS exam 勉強方法 4月から7月のおよそ3か月間の学習期間で、下記のような学習方法で勉強していました。 ・AWS主催のオンラインセミナーを受講する AWSが主催しているオンラインセミナーで概要の理解を深めたり、試験問題の解説講座を受講していました。 ・模擬試験を毎日解く 間違える度に、回答および解説をノートに記載していました。ひたすら書く! 解説を呼んでも理解できない問題は、なぜその答えになるのか同僚に質問して、解説いただいておりました。(感謝です!) インプット後にアウトプットできてこその理解だと思うので、自分なりに説明文を画用紙に書いて壁に貼ったり、全くAWSについて知らない家族に説明していました。 試験問題を解いていて、「似たような機能があったはずだけど、なんだっけ…?」と思い出せないときは、ChatGPTに質問していました。 ・なかなか覚えられない用語は関連付けをする 模擬試験を何度も解いていると、徐々に自分の苦手な分野が見えてきます。私は”NATゲートウェイ”をどうしてもインターネットゲートウェイと混同して誤答してしまうことが多かったです。 インターネットゲートウェイ(IGW):プライベートネットワークとインターネット間の双方向通信を可能にします。 外部からのアクセスも受け入れることができます。 NATゲートウェイ(NAT):プライベートネットワークからインターネットへの通信のみ可能。 外部からプライベートネットワークへのアクセスはできません。 二つの機能のポイントは「外部からのアクセスを許すかどうか」です。 この違いを覚えられず、練習問題でよく間違えていましたが、 ある日、たまたま観ていた映画の設定がNATゲートウェイと同じ役割をしていることにふと気づきました。 その映画は、小さな子供がモンスターの世界に迷い込むというストーリーです。 物語内の企業は、世界中の子供部屋の扉を管理しており、 モンスター世界と子供部屋をつなぐ役割を持っている設定があります。 ”モンスター世界から子供部屋にはアクセスできる” ”子供部屋からモンスター世界に自由に出入りはできない” 外部(子供部屋)からプライベートネットワーク(モンスター世界)へのアクセスはできない仕組みは、 まさに NATゲートウェイの動作 と同じです。 イラスト付きの教科書を読んだり、模擬試験を解いても頭に入ってこなかった二つの違いですが、 この映画を見てから、「NATゲートウェイは”モンスター世界の扉”」とイメージして覚えられるようになりました。 勉強に躓いた時には、気分転換のために一度離れてみると、新しい見方ができて活路が見いだせるかもしれません。 試験を受けてみての感想 90分はあっという間でした。 模擬試験で9割正答できるようになってから受験しましたが、いざ試験を受けてみると、考え込む時間が想定より長かったです。 悩む問題には、ひとまず”後で見返す”フラグをつけて、どんどん問題を解いていきました。 一通り解き終えて、フラグのついた問題を振り返った際に、日本語から英語表記に戻してみると、閃いたり。。。 問題の正解が AWS Pricing Calculator であることはわかっていたのですが、選択肢には「AWS料金計算ツール」と日本語で書かれていて最初は気づけませんでした。英語表記に置き換えてみたところ「AWS Pricing Calculator」と一致することがわかり、正しく選択できました。 さいごに 今回の学習を通じて実感したのは、「見方を変えること」や「自分なりにイメージしやすい工夫をすること」が理解を深める大きな助けになるという点です。模擬試験や参考書だけでは覚えづらかった内容も、身近な例や映画のワンシーンに置き換えることで、自然と頭に入ってきました。 AWSの勉強は決して楽なものではありませんが、工夫して楽しみながら取り組むことで、続けやすく、成果にもつながると感じています。 次の目標は SAA(ソリューションアーキテクト アソシエイト) 。基礎を固めた今だからこそ挑戦できる試験だと思うので、引き続き頑張っていきたいと思います。