SCSKの畑です。 弊社 AWS 環境で開発したアプリケーションをお客さんの AWS 環境に移行したのですが、移行当初は正常動作しなかったため、原因切り分けのためにタイトルの内容を試しました、という内容となります。   背景 お客さんの AWS 環境（AWSマネジメントコンソール）上から実行できるオペレーションが IAM 権限により限定されていた、という話は 初回のエントリ でも説明した通りなのですが、構築や実装に使用する変更関連の権限だけでなく、参照関連の権限についても付与対象が絞られていました。その1つとして 「IAM ロール/ポリシーに割り当てられている IAM 権限が確認できない」 という制限がありました。 元々このお客さんの AWS 環境は過去フェーズの案件も含めて数年前から使用していたのですが、当初は StepFunctions や Lambda を使用して Redshift にデータを投入するための ETL/ELT を実装するような内容がメインでした。元々バックエンド側の開発はフロントエンド側と比較して手慣れていたことや、エラー発生時にまず確認すべき CloudWatchLogs には参照権限があったため、この制限があってもそこまで問題を感じていませんでした。（もちろんこれが原因でエラーの切り分けに苦労したことも過去ありましたが・・）また、切り分けの結果 IAM 権限の問題が疑われる場合に設定内容の開示や追加設定をお願いすることは問題ありませんでした。 ただ、本案件事例にて実装したアプリケーションはこれまでと異なりフロントエンド/バックエンド両方の開発要素を含んでおり、かつ使用するサービスも多いため、これまでと比較してエラー発生時の原因切り分けや究明に手間取ってしまうことがありました。今振り返ると、今回取り上げる内容もその延長線上にあったのだなと思いますが・・   アプリケーション移行後の動作確認中にエラー発生 冒頭で記載した通り、弊社 AWS 環境で開発したアプリケーションをお客さんの AWS 環境に移行した後の動作確認中に、Cognito ユーザ認証後にクライアント側から AppSync API を叩いたタイミングで以下のようなエラーが発生しました。 { message: "Unauthorized", recoverySuggestion: `If you're calling an Amplify-generated API, make sure to set the "authMode" in generateClient({ authMode: '...' }) to the backend authorization rule's auth provider ('apiKey', 'userPool', 'iam', 'oidc', 'lambda')` } 先にエラー発生の原因についてネタばらししてしまうと、単純に Cognito ID プールの「認証されたロール」経由で付与される IAM ポリシーにおける appsync:graphql 権限の resource 句が正しく設定されていなかったことにより、結果として同 IAM 権限が不足していたことによるものでした。（本案件事例における AppSync の 認可方式については、 このエントリ の内容をご参照ください） ところが、上記アプリケーション側のログからだけでは当初原因が掴めませんでした。 message の内容は「Unauthorized」という単語のみなので原因究明には不十分であり、かつ Cognito ユーザ認証後に AppSync API を叩いている以上 Unauthorized と判定されている理由からしてそもそも良く分からない。 recoverySuggestion の内容は Amplify のスキーマ定義における @auth 句の設定に関する内容と思われ、そもそも弊社環境においては同じ設定で問題なく動作している以上、設定変更しても本質的な解決に繋がらないことが推測されたのでこちらも情報としては参考にならないと判断。 では AppSync のログに何かしら出ているのでは？と考えて CloudWatchLogs を見てみたのですが・・ { "logType": "RequestSummary", "requestId": "eafb8d66-f76c-4100-a836-e860dbca1808", "graphQLAPIId": "<graphQLAPIId>", "statusCode": 401, "latency": 63460261 } bd4f8c67-6eb0-4c98-8c6a-432e6f9f57dd Response Headers: {x-amzn-ErrorType=UnauthorizedException} 以上のように、ほぼアプリケーション側のログと同じ程度の情報量しかなかったため、同じく参考にならず。 なお、本エントリの作成にあたり手元の環境で再現試験を実施してみたのですが、AppSync のログレベルを「すべて」に設定変更してもログの情報量は特に変わりませんでした。。 クライアントから AppSync API を叩いているタイミングでエラーが発生している以上、現時点ではこれ以上のログ情報が出力されていないことから、改めてこの「Unauthorized」というメッセージから原因を考えてみたのですが、 Cognito の「認証されたロール」で指定している IAM ロール/ポリシーに appsync:graphql 権限が付与されていない Cognito でのユーザ認証後、「認証されたロール」で指定している IAM ロールが何らかの原因で正常に AssumeRole されていない のどちらかではないかと考えました。理由は以下の通りです。 先述した通り Cognito ユーザ認証については成功しており、ユーザ未認証の状態で実行されたとは考えがたい。 そもそもユーザ未認証ではアプリケーション上から AppSync API を実行する画面に遷移しない。 つまり考えられる可能性は、正常に「認証されたロール」で指定している IAM ロールが AssumeRole されなかったか、AssumeRole されたものの IAM 権限が不足しているか、のどちらかと推測。 バックエンド用の Lambda からは AppSync API が正常に実行できていることから、AppSync 側の設定については一旦考慮外。 厳密には個々のスキーマ/リゾルバ/関数定義などが誤っている可能性はあるが、そもそも AppSync API の実行すらできないことを鑑みるとそれ以前の問題と判断。 この内、1.については先述した 「IAM ロール/ポリシーに割り当てられている IAM 権限が確認できない」 制限があることから直接 IAM ロール/ポリシーの設定確認ができなかったため、弊社環境で再現試験を実施したところ同じようなエラーメッセージが発生することを確認できました。2.については以下の理由より可能性は低いと考えられたため、1.の可能性が濃厚という結論になりました。 「認証されたロール」に指定した IAM ロールが設定されていることがお客さんの AWS 環境上で確認できている。 上記を踏まえると、正常に AssumeRole できない原因は IAM ロールに設定するCognito ID プールとの信頼関係設定程度しか思い付かなかったが、弊社環境で意図的に設定を間違えた場合は以下のように別のエラーが発生することが分かったためこの可能性はなし。とすると他の可能性が思い浮かばない。。 InvalidIdentityPoolConfigurationException: Invalid identity pool configuration. Check assigned IAM roles for this pool. ただ、よりにもよってこの事象が発生したタイミングが、 お客さんから「認証されたロール」に設定している IAM ロール/ポリシーの設定（修正）が完了したと連絡を受けた直後 だったのですよね・・。経緯として、元々こちらから設定依頼した IAM ロール/ポリシーの内容が一部不正確だったため修正を依頼していたのですが、その対応をお客さんが完了したと言ってきた側から設定内容の開示や再修正を再度お願いするというのは、お客さんに対して 「エラー出てるんだけど本当にできてるんですよね？大丈夫ですか？」 みたいなニュアンスを言外に含んでいると捉えられかねないと憂慮してしまい・・内部で相談したところ、念のためもう少し裏取りしてから打診しようという方向性になりました。 もちろん、お客さん（フロント）とはある程度フランクにコミュニケーションを取れるような関係性はあるのですが、厳密にはお客さんの AWS 環境を管理しているのはお客さん（フロント）とは別の組織であったことから、そのあたりも考慮するともう少し慎重に進めた方が良いなと・・ 具体的には、2.の可能性の有無（＝AssumeRole 自体が正常に動作しているかどうか）までをお客さん AWS 環境で確認してから、対象 IAM ロール/ポリシーの設定内容の開示や再修正をお願いすることにしました。お客さん AWS 環境上の権限不足で確認できない場合は一旦諦める他ないですが、打診する前にできることはやっておこうということで。   本題 ということでようやく本題です。調べたところ、AssumeRole のログは CloudTrail に出力されるとのことで、お客さん AWS 環境で CloudTrail を開いたところ問題なく中身が見られたので、ログの確認を進めました。 AWS CloudTrail による IAM および AWS STS の API コールのログ記録 - AWS Identity and Access Management AWS STS による IAM および AWS CloudTrail のログ記録について説明します。 docs.aws.amazon.com 具体的には、上記 URL における 「AssumeRoleWithWebIdentity」 イベントが該当します。よって、お客さん AWS 環境のアプリケーションから意図的にエラーを発生させた上で、同時刻前後に「AssumeRoleWithWebIdentity」イベントが発生しているかどうかを確認しました。 その結果、以下スクリーンショットのような「AssumeRoleWithWebIdentity」イベントが発生しているログが確認できました。また、「参照されたリソース」の黒塗りしているリソース名が、Cognito ID プールの「認証されたロール」に設定している IAM ロールと同一でした。よって、アプリケーションから AppSync API を実行しようとした時に、想定通りの IAM ロールが Cognito ID プール 経由で AssumeRole されていることが確認できました。 よって、先述の方針通り Cognito ID プールの「認証されたロール」に設定している IAM ロール/ポリシーの設定が誤っている可能性が高いと判断しお客さんに設定内容の開示及びを依頼したところ、冒頭に記載した通り appsync:graphql 権限の resource 句が正しく設定されていなかったことが判明したため、再修正を依頼して無事クローズと相成りました。 以下の CloudTrail スクリーンショットやログは弊社環境で再現したものです。ご了承ください。 ちなみに、JSON 形式の CloudTrail ログも同画面から以下のように確認できます。今回確認したかった観点は上記画面から確認できたため、詳細については本エントリでは省略します。 { "eventVersion": "1.08", "userIdentity": {   "type": "WebIdentityUser",   "principalId": "cognito-identity.amazonaws.com:<COGNITO_APP_ID>:<COGNITO_APP_USR_NAME>",   "userName": "<COGNITO_APP_USR_NAME>",   "identityProvider": "cognito-identity.amazonaws.com" }, "eventTime": "2025-02-24T14:15:12Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRoleWithWebIdentity", "awsRegion": "ap-northeast-1", "sourceIPAddress": "<SOURCE_IP_ADDRESS>", "userAgent": "aws-internal/3 aws-sdk-java/1.12.780 Linux/4.14.355-275.582.amzn2.x86_64 OpenJDK_64-Bit_Server_VM/25.432-b06 java/1.8.0_432 kotlin/1.3.72 vendor/Oracle_Corporation cfg/retry-mode/standard cfg/auth-source#imds", "requestParameters": {   "roleArn": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/service-role/<COGNITO_ROLE_NAME>",   "roleSessionName": "CognitoIdentityCredentials" }, "responseElements": {   "credentials": {     "accessKeyId": "ASIA5NBR5LH3GUDX65GT",     "sessionToken": "<ENCODED_SESSION_ROKEN_BLOB>",     "expiration": "Feb 24, 2025, 3:15:12 PM"   },   "subjectFromWebIdentityToken": "<COGNITO_APP_USR_NAME>",   "assumedRoleUser": {     "assumedRoleId": "AROA5NBR5LH3HYAQNDM6Y:CognitoIdentityCredentials",     "arn": "arn:aws:sts::<AWS_ACCOUNT_ID>:assumed-role/<COGNITO_ROLE_NAME>/CognitoIdentityCredentials"   },   "provider": "cognito-identity.amazonaws.com",   "audience": "<COGNITO_APP_ID>" }, "additionalEventData": {   "identityProviderConnectionVerificationMethod": "IAMTrustStore",   "RequestDetails": {     "endpointType": "regional",     "awsServingRegion": "ap-northeast-1"   } }, "requestID": "ef3bb0c4-ed23-472e-9a93-3377cd9928dc", "eventID": "93c286a7-1732-4428-93e5-15875fa6b2a3", "readOnly": true, "resources": [   {     "accountId": "<AWS_ACCOUNT_ID>",     "type": "AWS::IAM::Role",     "ARN": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/service-role/<COGNITO_ROLE_NAME>"   } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "<AWS_ACCOUNT_ID>", "eventCategory": "Management", "tlsDetails": {   "tlsVersion": "TLSv1.3",   "cipherSuite": "TLS_AES_128_GCM_SHA256",   "clientProvidedHostHeader": "sts.ap-northeast-1.amazonaws.com" } }   まとめ つらつら書いていたら、本題より前段の話題である背景やエラー発生時の原因切り分けの内容の方が長くなってしまいました。すみません。ただ、お客さんの AWS 環境へのアプリケーション移行に関しては、こちらのエントリで記載した内容も含め最終的に正常に稼働させるまで結構な労力を要したので、備忘がてら忘れない内にまとめておきたかったんですよね。後、具体的な解決策について記載するのはもちろん、そこに至るまでの思考のプロセスも合わせてまとめておいた方が、少なくとも自分にとってはより有意義な記録になるというのもあります。 いずれにせよ、本記事がどなたかの役に立てば幸いです。

こんにちは、広野です。 個人的に JPCYBER S3 Drive という、Amazon S3 バケットを Windows のエクスプローラで操作できるツールを使い始めまして、ファイルサーバ代わりにしています。若干レスポンスは遅いですが、Amazon S3 ユーザーにとっては想像以上に便利です。Microsoft OneDrive と同じじゃん、って言われたらそれまでなんですが。w このツールは Windows に設定用のアプリをインストールして、アクセスしたいバケット名と IAM アクセスキーを入れれば使用開始できます。当然ですが AWS 側であらかじめ IAM ユーザーとアクセスキーを作成しないといけないので、それを AWS CloudFormation で作成しました。 今回は具体的な例になりますが、他の似たような用途で IAM アクセスキーが必要なケースにも応用できると思います。 要件 JPCYBER S3 Drive のドキュメントに、必要な IAM ユーザーの最小権限が掲載されていました。 Amazon S3のアクセスに必要な最低限のIAMポリシーの設定 - JPCYBER AWS Amazon S3 バケットにアクセスするために必要な最低限の IAM ポリシーの設定は、以下のように設定してください。（IAM ユーザー、または IAM ロールの設定で、既に「AmazonS3FullAccess」ポリシーをアタッ... www.jpcyber.com これをベースに AWS CloudFormation テンプレートを作成します。 Amazon S3 バケットは作成済みとします。 作成する IAM ユーザーではマネジメントコンソールへのログインはできません。(権限もパスワードもない) アクセス可能な S3 バケットは指定した 1 つだけです。他へのアクセスはできません。 作成されたアクセスキーは AWS Secrets Manager で参照できます。 AWS CloudFormation テンプレート 作成したい IAM ユーザー名と、アクセスしたい Amazon S3 バケット名をパラメータに入力して実行します。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates an IAM user with the grant to access the specific S3 bucket only. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: IamUserName: Type: String Description: The IAM user name. Default: S3BucketAccessOnly MaxLength: 100 MinLength: 5 AllowedPattern: ^[A-Za-z0-9_+=,.@-]+$ S3BucketName: Type: String Description: The target S3 bucket name. Default: bucketname MaxLength: 63 MinLength: 3 AllowedPattern: ^(?!.*\.\.)[a-z0-9]([a-z0-9-]{1,61}[a-z0-9])?$ Resources: # ------------------------------------------------------------# # IAM User # ------------------------------------------------------------# IamUser: Type: AWS::IAM::User Properties: UserName: !Ref IamUserName Path: / # ------------------------------------------------------------# # IAM User Policy # ------------------------------------------------------------# IamUserPolicy: Type: AWS::IAM::UserPolicy Properties: UserName: !Ref IamUser PolicyName: !Sub ${IamUserName}-${S3BucketName} PolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: "s3:ListAllMyBuckets" Resource: "arn:aws:s3:::*" - Effect: "Allow" Action: - "s3:ListBucket" - "s3:ListBucketVersions" - "s3:GetBucketACL" Resource: !Sub "arn:aws:s3:::${S3BucketName}" - Effect: "Allow" Action: - "s3:GetObject" - "s3:PutObject" - "s3:AbortMultipartUpload" - "s3:DeleteObject" - "s3:GetObjectVersion" - "s3:DeleteObjectVersion" - "s3:GetObjectACL" - "s3:PutObjectACL" Resource: !Sub "arn:aws:s3:::${S3BucketName}/*" DependsOn: - IamUser # ------------------------------------------------------------# # IAM Access Key # ------------------------------------------------------------# AccessKey: Type: AWS::IAM::AccessKey Properties: Serial: 1 Status: Active UserName: !Ref IamUser DependsOn: - IamUser # ------------------------------------------------------------# # Secrets Manager # ------------------------------------------------------------# Secret: Type: AWS::SecretsManager::Secret Properties: Name: !Sub IamAccessKey-${IamUserName} Description: !Sub IAM Access Key for the IAM user ${IamUserName} SecretString: !Sub "{\"accessKeyId\":\"${AccessKey}\",\"secretAccessKey\":\"${AccessKey.SecretAccessKey}\"}" DependsOn: - AccessKey 結果 AWS CloudFormation テンプレートを実行すると、指定した名前の IAM ユーザーが作成され、アクセスキーが発行されます。アクセスキーの情報は、以下のように AWS Secrets Manager で参照可能です。   この値を使用して、無事 JPCYBER S3 Drive を使用することができました！   まとめ 本記事の仕様は、セキュリティ面で個人使用限定の AWS アカウントであったり、他の IAM ユーザーの権限管理をきっちりできていたりする状況でないと使いづらいと思いますが、外部ツールから AWS にアクセスさせる要件に応用できると思います。 AWS Secrets Manager にアクセスキー情報を格納することで、作成後もキー情報を参照することができます。ただしセキュリティ的にそうやって残しておくのが良いのか？というと微妙ではありますが、どこかに情報を保存して忘れたーとなるのもどうかと思いますので、これを良しとするかは判断が必要です。また、AWS Secrets Manager の料金がかかってしまうのはデメリットです。 記事では書いていませんが、Amazon S3 バケットへのアクセスログ取得とセットで使いたいですね。 本記事が皆様のお役に立てれば幸いです。

こんにちは、SCSK の松山です。 Amazon Aurora DSQL (以下 DSQL と略す) について、従来の PostgreSQL との差異に焦点をあてて調べてみたシリーズ、前回(第一弾)は、DSQL の簡単な要約と構築についてお伝えしました。 Amazon Aurora DSQL について調べてみた (構築編) Amazon Aurora DSQL について従来の PostgreSQL との差異に焦点をあてて調べてみたシリーズ第一弾。第一弾は DSQL の簡単な概要と構築編です。 blog.usize-tech.com 2025.03.17 Amazon RDS や Amazon Aurora、オンプレの PostgreSQL と比較して、非常に簡単に構築できることがわかりました。 第二弾として、本件では 従来の PostgreSQL と比較した場合の機能制限 に焦点をあててまとめていきます。 ※本件は 2025/3 時点の Amazon Aurora DSQL User Guide – PostgreSQL compatibility を参考に記載しました。 DSQL は 2025/3 現在プレビュー版のため、今後機能の追加によって制限が変更されることが想定されます。 実際に DSQL を使用する場合は、その時点の最新マニュアルを合わせてご確認ください。    DSQL の制限を知る重要性 DSQL は PostgreSQL と一部機能の互換性があると発表されていますが、完全な互換性を保証するものではありません。そのため、従来の PostgreSQL と同じ構成ができるつもりで DSQL を使い始めた場合、予期せぬ問題に直面する恐れがあります。 DSQL を有効活用するためにも、まずはできること、できないことを正確に把握しておくことが重要です。 DSQL の制限 以下、いくつかの項目に分けて制限事項をまとめていきます。 オブジェクトの制限 以下のオブジェクトはサポートされていません。 Database (DSQL 作成時に作られる Database 以外は追加できない) View Temporary Table Trigger Type Tablespace Sequence Materialized View Procedure SQL 以外を使用する Function Foreign key (参照整合性制約) Exclusion constraint (排他制約) Function に関しては、SQL のみを使用した単純な構成の物は作成することが可能です。 (後述しますが、DSQL では plpgsql をサポートしていません) Procedure や Function、Trigger などのソースコード系オブジェクトが制限されている点から、Database 内で複雑な処理を行う使用方法は想定されていないと考えられます。 また RDBMS として利用頻度の高い参照整合性制約がサポートされていない点は抑えておきたいポイントです。 オペレーションの制限 以下のオペレーションはサポートされていません。 ALTER SYSTEM TRUNCATE VACUUM SAVEPOINT 従来の PostgreSQL として特徴的な VACUUM が手動実行できない点は抑えておきたいポイントです。 SQL の制限 DSQL では SQL の一部構文がサポートされていません。 全てを網羅的には公開されていませんが、マニュアルより以下をサポートしていない点が確認できます。 CREATE 「オブジェクトの制限」に記載した各種オブジェクト 拡張機能の追加 (EXTENTION) CREATE INDEX ソート順 (ASC、DESC)  CREATE TABLE AS SELECT  照合順(COLLATE)  テーブルの継承(INHERITS)  パーティション(PARTITION)  データ型の制限 データ型については大きく分けて3つのポイントがあります。 サポートされるデータ型の制限 DSQL でサポートされているデータ型が Amazon Aurora DSQL User Guide Supported data types in Aurora DSQL  に記載されています。記載されていないデータ型については、動作するかを個別に確認する必要があります。    データ型のサイズ制限 サポートされているデータ型に対しても、DSQL 独自のサイズ制限が設けられているケースがあります。そのため、合わせて確認が必要です。                        DSQL のデータ型 サイズ制限 Name Implicit Limit character [ (n) ] 4096 bytes bpchar [ (n) ] 4096 bytes character varying [ (n) ] 65535 bytes text 1MB bytea 1 MB numeric [ (p, s) ] numeric (18,6) Primary Key および 索引付与の制限 以下のデータ型は Primary Key や 索引を付与することができません。                        bytea numeric timestap with time zone interval 　特に numeric は使用頻度の高いデータ型のため、DSQL への移行を検討している場合には留意が必要です。 拡張機能の制限 従来の PostgreSQL にはさまざまな拡張機能が存在します。 マニュアルでは例として、以下代表的な拡張機能をサポートしていない旨が記載されていました。 PL/pgSQL PostGIS PGVector PGAudit Postgres_FDW PGCron pg_stat_statements しかし「SQLの制限」に記載した通り、拡張機能を追加するための CREATE EXTENTION がサポートされていません。 そのため、拡張機能は全般的にサポートされていないと考えたほうがいいでしょう。 システム管理表 および 管理ビューの制限 DSQL はメンテナンスを含めてサービスに任せる運用になります。 そのため、多くのシステム管理表 および 管理ビューに情報が出力されません。 どのシステム管理表 および 管理ビューに対応しているかは Amazon Aurora DSQL User Guide Using system tables and commands in Aurora DSQL に記載されています。 DSQL のサービス上、DBA としての作業はあまり発生しないと考えられますが、頭の片隅に入れておくといいかと思います。 トランザクションの制限 トランザクションには以下の制限が設けられています。 接続は1時間を超えることはできない トランザクションに DDL と DML を混在させることはできない トランザクションに含められる DDL は最大1つ トランザクションは10,000行を超える更新を行うことはできない (索引が付与されている場合、索引更新行数も制限内に含まれる) 実行時間に制限がある点や、1トランザクションの更新量に制限がある点からも、複雑な処理の実行は想定していないことが伺えます。 なお1トランザクションの更新量については、索引の付与状況によってさらに減少するという記載がありました。 この点はマニュアルの記載からは把握が難しいため、今後のシリーズにて実機検証を踏まえた内容をまとめていきます。 まとめ DSQL では従来の PostgreSQL と比較して、さまざまな制限があることがわかりました。 制限されている内容から、従来の PostgreSQL のような Database 内で複雑な処理を行うことは想定していない と考えます。 分散SQLデータベース かつ 事実上無制限のスケーラビリティを提供している点から、単純 かつ 短時間で完了するクエリが大量に同時実行されるようなシステム( OLTP系の処理 )に適しているのではないでしょうか。 DSQL は 2025/3 現在まだプレビュー中のため、今後機能の追加によって制限が緩和されることにも期待したいと思います。 次回は DSQL と 従来の PostgreSQL で大きな違いとなる トランザクションの同時実行制御の差異 を深堀していきます。 ご興味のある方は引き続きご確認いただければ幸いです。

Catoクラウドのクライアントソフトに、待望のAnti Tampering機能が実装されます! この機能追加により、 ユーザによるCatoクライアントのプロセス停止やアンインストールを禁止できます。 本記事では、Anti Tamperingの概要と、動作確認の結果をご紹介します。 本機能は、2025/3/18時点でEarly Availabilityとして提供されています。正式リリース時には機能が変更となる可能性がありますので、ご留意ください。 Anti Tampering(改ざん防止)とは Anti Tamperingは「改ざん防止機能」と訳され、通信・セキュリティ系のソフトウェアに搭載されることの多い機能です。 悪意ある侵入者やマルウェアは、自分の動作を検知されることを避けるため、端末の管理者権限を取得し、ソフトウェアの設定を変えたり、ソフトウェア自体を終了させたり、ログを削除・改ざんしたりします。これを防ぐため、端末の管理者権限を持っていても、ソフトウェアの終了や関連ファイルの書き換えを許可しないのがAnti Tampering機能です。 今回、Catoクライアントにこの機能が追加されたことにより、 Catoクラウドがよりセキュアなサービスになった と言えます。 CatoクラウドのAnti Tampering機能について CatoクラウドにおけるAnti Tampering機能は、2025/3/18現在、以下の内容となっています。 対象: Windowsクライアント バージョン5.14以上で対応 現状はWindowsのみですが、将来的にmacOSクライアントにも実装予定です 制限できる内容 Catoクライアントのアンインストールをさせない CatoVPNのプロセス停止をさせない Catoクライアントの動作に影響するレジストリの変更をさせない インストールフォルダ内のファイル削除・変更をさせない (ログファイル・設定ファイル等の保護) 詳細については、以下のCato Knowledge Baseをご参照ください。 Cato KnowledgeBase | Working with Anti-Tampering for the Cato Client それでは、どのように設定を行うのか、また本当に上記を制限できているのか等、検証した内容をご紹介します。 Anti Tamperingの設定方法 Cato管理画面(CMA)側の設定 Anti Tamperingの利用には、まず機能を有効化する必要があります。Anti TamperingはAlways-On(常時接続)機能の追加機能となっており、Cato管理画面(CMA)の「Always-On Policy」の箇所にて設定します。 以下がルールの設定例です。 対象としたいユーザ・OS等を指定して、Always-Onを有効にすると、Anti Tamperingの設定項目が選択できるようになります。こちらをEnabledにすることで、Anti Tamperingが有効になります。 なお、Always-On Policy自体の使用や設定方法については、以下の記事にて詳細をご紹介しておりますので、ご参照ください。 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 クライアント側での確認 CMAを設定後、Catoクライアントを接続し10分程度置くと、Cato側からクライアントへ設定内容が反映されます。 CatoクライアントのStatsにて、Anti-Tamper Protectionの欄が「Enforced(Protect)」となっていれば、Anti Tamperingが適用されています。 ※この項目自体が表示されない場合は、Windowsクライアントのバージョンが古いため、5.14以上にアップグレードしてください。 本当に停止できないのか検証 Anti Tamperingが有効な状態で本当にクライアントを停止できないのか、実際に検証してみました。もちろんWindows端末のAdministratorで試しています。 アンインストール Anti Tamperで保護されている旨のエラーが表示され、 アンインストールできません 。Catoクライアントのアンインストーラーでも、設定>アプリからのアンインストールでも、MsiExec.exeを使ったコマンドライン操作でも、同じエラーとなります プロセス・サービス停止 タスクマネージャのプロセスから、「CatoClient」をタスク終了してみますと、終了でき、Catoクライアントのアプリが表示されなくなります。 しかしながら、Catoの接続は切断されず、接続されたままです。サービスを確認すると「CatoNetworksVPNService」が実行中となっており、接続が維持されていることが確認できます。 このサービスを停止しようとすると下記のエラーとなります。このため Catoへの通信を切断することはできません。 また、サービスを無効化することもできません。 レジストリ変更 Catoクライアントの実行に関連するレジストリキーを変更や削除しようとすると、エラーとなり、レジストリ変更ができません。このため、レジストリ操作でCato接続を停止することはできません。 実行ファイル・ログファイル等の削除・改ざん Catoクライアントの実行ファイルや各種ログがあるフォルダにて、ファイルを変更や削除しようとすると、エラーとなり、ファイル編集できません。これにより、Cato接続を動作不能にしたり、ログファイルを改ざんすることはできません。 ネットワークアダプタの停止 Cato Networks VPN Adapterを無効化してみました。無効化はできますが、Catoへの通信は切断されません。メトリック値を変えてみたりもしましたが、通信には影響せず、Catoを迂回することはできませんでした。 以上、思いつく限りの手段を試してみましたが、Anti Tamperingが有効な状態で、Catoを無効化し通信迂回することはできませんでした。 他に試せそうなことがありましたら、ぜひ検証いただければと思います。 アンインストールしたいときはどうするか では、運用上の事由などで、どうしてもAnti Tamperingを回避したいときはどうしたらいいのでしょうか。 まず、一時的にCatoの通信を切断したいだけで、クライアントのアンインストールは不要な場合、Always-Onを一時的にBypassし通信を切断することが可能です。Always-OnのBypass方法については、以下のCato Knowledge Base をご参照ください。 Cato Knowledge Base | Temporarily Bypassing Secured Internet Access 次に、クライアントをアンインストールしたい場合は、以下いずれかの方法で可能です。 Always-On Policyにて対象ユーザに対するAnti Tamperingを解除した上でアンインストールする Anti-Tamper Bypass を使用し、 一時的に Anti Tamperingを解除した上でアンインストールする このうち、Anti-Tamper Bypassについては少しわかりづらいため、以下に詳細をご説明します。 Anti-Tamper Bypass Anti Tamperingを一時的に無効化する機能です。 1. Always-On Policyの「Settings」にある、「Show anti tamper bypass code」を開くと6桁の数字が表示されます。このコードには有効期限があり、コードの下に表示される時間の間のみ有効です。 2. 無効化したいCatoクライアントの「Settings」を開き、「Ctrl+Shift+O」を押すと、「Anti-Tamper Bypass」の入力欄が表示されます。 3. 1のコードを2に入力して「Submit」すると、一時的にAnti Tamperingが無効化され、アンインストール等が可能となります。 なお、無効となる時間の長さは、Always-On Policyのルールにて設定可能です。 最後に Anti Tamperingは、ユーザの意図しないアンインストールなどを防ぐため、多くのお客様からご要望をいただいていた機能です。 ユーザの通信保護に大きく寄与する機能ですので、ぜひご検証の上、ご活用いただければ幸いです。

こんにちは、SCSK の松山です。 2024/12/2～12/6 米国ラスベガスで開催された AWS 最大のカンファレンス re:Invent 2024 にて Amazon Aurora DSQL (以下 DSQL と略す) が発表されました。 DSQL は PostgreSQL と一部互換性を持っていると発表されています。 この点から従来の PostgreSQL との差異に焦点をあてて DSQL について調べてみました。 その結果を数回にわけてまとめていきたいと思います。 第一弾として、本件では  DSQL の構築 についてまとめていきます。 ※本件は 2025/2 時点の検証結果をもとに記載しています。 　今後動作が変更される可能性がある旨、ご注意ください。 前提：DSQL とは DSQL の構築を行う前に、まずは re:Invent 2024 で発表された DSQL の説明をまとめてみました。 DSQL の特徴 高い可用性を備えたサーバレスな分散SQLデータベース 障害復旧の自動化 事実上無制限のスケーラビリティ インフラ管理(パッチ適用など) が不要 PostgreSQL と一部機能の互換性がある Amazon RDS や Amazon Aurora においても、通常の Database 構築と比べて簡易化されていますが、DSQL ではさらに管理面を含めて自動化されています。 サーバーレスのため、DBインスタンスのエンジン選択や Database のパラメータ設定などがありません。 本来大きなコストを要する Database の設計、メンテナンス、障害復旧が自動化されている点が大きなメリットと言えるでしょう。 考慮が必要な点 PostgreSQL と完全な互換性を保証するものではない 従来の PostgreSQL とはトランザクションの同時実行性管理方法が異なる 1トランザクションで更新可能な件数や実行時間に制限がある PostgreSQL と互換性はありますが、アーキテクチャに違いがあるため、この点は十分に考慮が必要です。 また従来の PostgreSQL は基本的に単一インスタンスでの動作を前提としていますが、 DSQL は分散SQLデータベースです。 そのため、パフォーマンスを引き出すためには、従来の PostgreSQL とは異なるオブジェクト設計を検討する必要があります。 DSQL を構築する ※2025/3 現在、DSQL はプレビュー版のみ公開されています。 　プレビュー版に対応しているリージョンは、 バージニア または オハイオ のみ です。 AWS コンソールにログイン    「DSQL」で検索し、 「Amazon Aurora DSQL」のページへ移動    バージニア または オハイオ リージョンを選択 東京リージョンで DSQL のページへ移動した場合リージョン変更を求められるため、バージニア または オハイオを選択します。    「Create cluster」をクリック    初期設定後、「Create cluster」をクリックし DSQL を構築 設定項目はマルチリージョンの有無とタグ設定のみです。                             「Cluster settings」 でマルチリージョンの有無を設定 マルチリージョン構成にする場合、「Add linked Regions」にチェックを入れます。 本件では以下を選択しています。                    Linked cluster Region us-east-2(Ohio) Witness Region us-west-2(Oregon) 「Deletion protection」はデフォルトでチェックが入っているため、そのままの設定にします。 「Tags」に任意のタグを設定 「Create cluster」を実行 Aurora DSQL のコンソールへ画面が推移します。 「Status」が「Active」に変化したら、構築完了です。    【構築中】    【構築完了】                      状態確認 マルチリージョンで構築した場合、バージニアとオハイオ それぞれに DSQL が構築されます。 双方のクラスタ状態について以下の方法で確認します。                               構築元(今回の場合バージニア) ：表示されている 「Cluster ID」 をクリック     マルチリージョン先(今回の場合オハイオ)：オハイオリージョンへ移動し、Aurora DSQL 画面を確認 構築直後の場合は、メッセージに表示されている「us-east-2(Ohio)」のリンクから直接移動が可能です。                        上記のメッセージを消している場合は、リージョン オハイオを選択し DSQL の画面へ移動し、対象DSQLの「Cluster ID」 を選択します。    接続確認 対象リージョンの AWS CloudShell から簡易接続テストを行います。                               AWS CloudShell を表示 画面上部の CloudShell アイコンをクリックし、CloudShell 画面を表示します。    DSQL の「Connect」をクリックし、エンドポイントをコピー                       AWS CloudShell から psql 接続 (パスワード入力前まで進める) psql のオプションには以下を指定します。   –dbname postgres –username　  admin –host Ⅱでコピーしたエンドポイント     DSQL の「Connect」をクリックし、パスワードをコピー                       AWS CloudShellにパスワードを入力 ※PostgreSQL バージョンの関係で WARNING が出力されていますが、DSQL 環境に接続出来ている状態です。    同様の確認をマルチリージョン先でも実施 (手順は省略) なお本件では AWS CloudShell から簡易検証していますが、プログラムから接続することも可能です。 各プログラムから接続を行うサンプルコードは以下マニュアルに記載されています (本件では詳細は割愛します) Programming with Aurora DSQL  以上で DSQL の構築は完了です。 まとめ 設定項目はマルチリージョンの有無のみであることがわかりました。 Database に対するスキルがない状態でも、非常に簡単に構築できる点にメリットを感じました。 プレビュー版を使用できる機会に触れてみるのはいかがでしょうか。 次回以降のシリーズでは、PostgreSQL と比較した制限や、本件で構築した環境を使用してアーキテクチャの差異を深堀していきます。ご興味のある方は引き続きご確認いただければ幸いです。

こんにちは、SCSKの前田です。 HAクラスターソフトウェアである LifeKeeper を利用するにあたり、一般的の用語や専門的の用語が出てきます。 今回は、皆さんがクラスターソフトを少しでも身近に感じられるよう、各用語について説明していきたいと思います。 HAクラスターとは？ LifeKeeper が HAクラスターソフトウェアと言うことで、HAクラスターから説明したいと思います。 この「 HA 」とは、「 High Availability 」、日本語に訳すと高可用性となります。 また「クラスター」とは、複数のサーバーをまとめて1台のサーバーとして見せるシステムの事を指します。 よって、HAクラスターとは、サーバーを複数台使用して、冗長化することで障害が発生したとしてもシステムの停止時間を最小限に抑え、業務の可用性(Availability)を向上させるクラスターシステムとなります。 もし、業務が稼働しているサーバーで継続が不可能な障害が発生した場合、他の正常なサーバーに業務の切り替えが行われ、システム全体として業務が継続されるようになっています。 業務用のアプリケーションが起動しているサーバーで障害が発生しても、違うサーバーで同じ業務用のアプリケーションが起動させるので、業務が続けられるんだね。 ノードとは？ 続いて、LifeKeeperでも良く登場する、ノードについて説明したいと思います。 「ノード」（node）とは、「結び目」「集合点」「節」といった意味になるようです。 Wikipediaによると、下記の通り項目によってさまざまな内容が出てきます。 ノード (ネットワーク) – ネットワークの節点。 ノード (グリーンランド) – グリーンランド北東部にある基地。 頂点 (グラフ理論) – グラフ理論における頂点や節点。ノードとも呼ばれる。 節点 (言語学) – 統語論において、範疇表示のある点。 Nord – クラビアのシンセサイザー製品。 Node.js – V8 JavaScriptエンジン上に構築されたJavaScript実行環境 そこで、LifeKeeperとしてのノードに関しては、ずばりクラスターを構成するサーバーの事を意味します。 例えば、1台のサーバーでご利用いただく Single Server Protection であれば1ノードでの構成になり、LifeKeeperを使って2台のサーバーでクラスターをご利用いただく場合、2ノードでの構成となります。 それ以上に可用性を高めるため3台のサーバーでクラスターをご利用いただく場合、3ノードでの構成になります。 　   　　　 LifeKeeperのライセンス購入も、ノード単位となっています。 リソースとは？ 「リソース」（resource）とは「供給源」「資源」「財源」など資源を意味する英語です。物質的なものに限らず、様々な分野における抽象化された資源を表す用語として広く使われいます。 LifeKeeperでは、保護する アプリケーション やファイルシステム(共有領域)や仮想IPアドレス等、「リソース」として管理しています。アプリケーションやファイルシステム毎を個別にリソースが作成され、作成されたリソースに対し、停止や開始が行えるとともに自動で監視が行われ、異常と判断された場合は自ノード上で再起動が行われます。（設定によってリソースの再起動を無効にすることが可能です。）それでも異常が解消しない場合は他ノードへの切り替えが自動的に行われます。 稼働系と待機系とは？ 「稼働系と待機系」とは、どの様な事なのでしょうか？ LifeKeeper等のHAクラスターソフトウェアとしては、複数台のノードを冗長化し、まとめて1つのノードとして見せるシステムになっています。 具体的には、複数台のノードでリソースが開始されているノードもあれば、リソースが開始されていない(停止されている)ノードも存在することになります。 このリソースが開始されているノードの事を稼働系ノードと言います。逆にリソースが停止されているノードの事を待機系ノードと言います。 フェイルオーバーとは？ LifeKeeperをはじめとしてHAクラスターソフトウェアで良く耳にする用語として、フェイルオーバーがあります。 この「フェイルオーバー」について説明したいと思います。 「フェイルオーバー」とは、稼働系ノードでサーバーやリソース等の問題が発生し、業務が続行できないような状態になった際、稼働系ノードから待機系ノードへリソースの状態を 自動的 に切り替えることを言います。 LifeKeeperでは、人の手を介入することなくソフトの観点から、ノードの異常やリソース（アプリケーション等）の異常を自動で検知し、障害と判断された場合は、自動的に稼働系ノードから待機系ノードに切り替えることで、業務を停止してしまう時間を極力減らすことが出来るソフトウェアになっています。 スイッチオーバーとは？ HAクラスターソフトウェアとして「フェイルオーバー」に似ている言葉として「スイッチオーバー」があります。 最後に「スイッチオーバー」について説明したいと思います。 稼働系ノードにてメンテナンスやバックアップ等、何らかの理由によりOSを停止する必要があるが、業務はそのまま停止したくない場合があります。そのため、稼働系ノードでの業務を待機系ノードに切り替える必要があります。 このように、稼働系ノードで開始しているリソースを 手動 で待機系ノードに切り替えることを「スイッチオーバー」と言います。 「スイッチオーバー」を実施することで、一旦稼働系ノードのリソースが停止され、待機系ノードでリソースが開始される処理が実行されるため、一時的に業務が途切れる事象が発生します。 そのため、「スイッチオーバー」を実施する際は業務が一時的に途切れても問題のない時間帯に実施する必要があります。 まとめ 今回はHAクラスターソフトウェアであるLifeKeeperで良く使われている用語について説明して来ましたが、いかがでしたでしょうか？少しでもLifeKeeperを身近に感じて頂けたら幸いです。 次回はLifeKeeperの内部で使われている機能の用語について説明したいと思いますので、お楽しみに！ 公式ホームページ： 「LifeKeeper」で安定稼働を実現 ｜ SCSK株式会社

こんにちは。SCSKの山口です。 今回は、BigQueryのテーブルにCSVデータを取り込む際、何度も遭遇したエラーたちと、その解消方法をご紹介します。 データを取り込む方法としては、下記「bq load」コマンドでGCS→BQに取り込むことにします。 実行コマンド bq load –skip_leading_rows=1 [データセット].[テーブル] gs://[バケット/フォルダ]/[ファイル名]  コマンドのオプション等、詳細情報は下記ドキュメントをご参照ください。 bq コマンドライン リファレンス   使用するテーブル情報です。 データが入ると祝福されます。   エラー①：データ内に「”」がある 原因データ こんなデータの時に発生します。 clm1（STRING）がご丁寧に「”」で囲まれているのと、濁点が「”」になってますね。（誰だこんなことしたのは。） 発生するエラー こんなエラーが発生します。 Data between close quote character (“) and field separator. エラー内容的には、「 引用符（”）と区切り文字（,）の間になんか変なヤツが居るよ 」みたいな感じですね。 構造化すると、最初の「””」のセットで囲まれている、 “おめで” 部分が「データ」として認識され、 とう” 部分が「変なヤツ」と認識されています。 実はこれ、 データの先頭に「”」がある場合 に発生し、「おめて”とう”」や「おめて”とう」のような場合は発生しません。   解消方法 入れたいデータに合わせて二パターン紹介します。   データ両端の「”」が不要な場合 BigQueryに「おめて”とう」の形で入れたい場合の解消方法です。 この場合は、データ内の「”」をエスケープしてあげることで解消できます。 わかりづらいですが、データ内の「”」は前に「”」をもう一つつけることでエスケープ可能です。 実行コマンド bq load –skip_leading_rows=1 yamaguchi_blog.bqinsert_error gs://yamaguchi_blog_bqerror/double_quote.csv おめて”とうございます。データが入りました。   データ両端の「”」が必要な場合 BigQueryに「”おめて”とう”」の形で入れたい場合の解消方法です。 この場合は、 引用符として別の文字を設定する のが一番簡単です。 bq loadのコマンドを使う場合、 デフォルトの引用符は「”」で設定 されています。この引用符を変更することで解消可能です。 下記コマンドを実行します。 実行コマンド bq load –skip_leading_rows=1 –quote=# yamaguchi_blog.bqinsert_error gs://yamaguchi_blog_bqerror/double_quote.csv 今回は「#」を引用符として設定しましたが、 データに含まれてなさそうな文字 を選ぶのがポイントです。 コマンドを実行すると、 “おめて”とう”ございます。データが入りました。   エラー②：データ内に「,」がある 原因データ CSVのデータ内に「,」があることで区切り位置がおかしくなり、「テーブルのスキーマ数とレコードのデータ数が合わないよ。」と怒られるエラーです。 こんなデータの時に発生します。 スキーマ数が2つなのに対し、データが３つになっていますね。 発生するエラー こんなエラーが発生します。 Too many values in line. Found X column(s) when expecting Y 「行内のデータが多すぎるわ、Y個だと思ってたらX個あったわ。」といった感じですね。 解消方法 本来ならばCSV形式のデータ内の「,」はご法度ですが、今回は特別に「,」がデータ内にある状態で取り込む方法をご紹介します。   データ全体を引用符で囲む 先ほども登場した、引用符が活躍します。 実行コマンド bq load –skip_leading_rows=1 yamaguchi_blog.bqinsert_error gs://yamaguchi_blog_bqerror/comma.csv おめ,でとうございます。データが入りました。   区切り文字をタブ文字に変更する 区切り文字の変更で回避することも可能です。 この方法は、大規模なデータの際に有効です。 データのエクスポート時に区切り文字を「タブ文字」に変更しておくことで、全データに対する置換処理を省くことができます。 わかりづらいですが、色付部分がタブ文字になってます。   実行コマンド bq load –skip_leading_rows=1 –field_delimiter=’\t’ yamaguchi_blog.bqinsert_error gs://yamaguchi_blog_bqerror/comma.csv 区切り文字（field_delimiter）をタブ文字に変更しています。   おめ,でとうございます。データが入りました。   エラー③：データ内に「改行」がある 原因データ データ内に改行が含まれる際に発生します。   発生するエラー こんなエラーが発生します。 CSV table references column position X, but line contains only Y columns. テーブルのX番目にあたるデータを見ようとしたけど、データがY個しかないよ。といった感じです。 データがまだ続くと思いきや改行があり、（実際には次の行にデータが続くが）その先データが無いように見えているのであれ？となっているんですね。   解消方法 改行許可オプションを使う 改行許可オプション「 — allow_quoted_newlines 」という便利なものが用意されています。これを使って解消します。 このオプションを使うには、データを引用符（デフォルトでは「”」）で囲む必要があります。   実行コマンド bq load –skip_leading_rows=1 — allow_quoted_newlines = true   yamaguchi_blog.bqinsert_error gs://yamaguchi_blog_bqerror/newline.csv 改行許可オプションを有効にしています。   おめ でとうございます。データが入りました。   まとめ BigQueryにCSVデータを取り込む際にあたったエラーを備忘録を兼ねてまとめました。 大規模データの際は、これらのエラーが複合的に出てくることがあります。 その際も、今回ご紹介した解消方法を組み合わせることで（だいたいは）解消可能です。 また新たなエラーに遭遇した際は共有します。

本記事は 新人ブログマラソン2024 の記事です 。 お疲れ様です。USiZEサービス部第三課の織田です。 今回はvCLSについてまとめてみました。 vCLSとは、私が仕事でよく利用するVMwareの製品の一つである、vSphereの機能の一つです。 vCLSが有効であるとどんないいことがあるのか、無効にするとどのような影響があるのか、を中心に調べてまとめました。   vCLSとは 初めにvSphere関連の用語を簡単に説明します。 用語 説明 仮想マシン ESXiホスト上で動作する仮想のコンピュータです。VM（Virtual Machine）と表記されることもあります。 ESXiホスト ESXiがOSとしてインストールされた物理的なコンピュータです。 仮想マシンはESXiホストのリソースを使用して稼働します。 クラスタ 複数のESXiホストの管理単位です。各ESXiホストのリソースを管理します。 vCenter vSphere環境全体を管理する中央管理ツールです。  ※以下はイメージ図です。わかりやすくするため、かなり簡略化しています。   vSphereのvCLS (vSphere Cluster Services) とは？ 今回紹介する vCLS (vSphere Cluster Services) は、vSphere 7.0 Update 1以降で導入されたクラスタの機能です。 ※参考サイト１，参考サイト２ vCLS機能を有効にすると、小さな仮想マシンが作成され、クラスタのリソース管理などを補助します。 以下はイメージ図です。 図のように、通常の仮想マシン（VM）よりも、小さな仮想マシンが作成されます。 参考サイト１： https://techdocs.broadcom.com/jp/ja/vmware-cis/vsphere/vsphere/8-0/vsphere-resource-management-8-0/vsphere-cluster-services-vcls.html （vSphereクラスタサービス） 参考サイト２： https://knowledge.broadcom.com/external/article?legacyId=80472 （vSphere Cluster Services (vCLS) in vSphere 7.0 Update 1 and newer versions） vCLSの主な役割 クラスタの健全性維持 vCLSはクラスタ内のホストが適切に機能しているかを監視し、クラスタ管理機能を維持します。 つまり、vSphere環境全体を管理するvCenterが一時的に利用できない場合でも、クラスタの一部機能が継続されます。 vCLSはvCenterが一時的に停止した際に、クラスタの健全性を代わりに維持する機能。 具体的な機能については、以下で説明します。   DRS (Distributed Resource Scheduler) の継続運用 DRSとは、「クラスタ内の仮想マシンのリソース配分を最適化する機能」です。 以下はイメージ図です。 図の説明をします。 はじめは左のESXiホストにVM（仮想マシン）が集中しており、各VMのリソース使用量が同じであるとした場合、各ESXiホストで使用されるリソースに不均衡が生じます。 DRSによって、各ESXiホストのリソース消費が均等になるようにVMの再配置が行われます。（この時VMはvMotionという機能によって無停止でホストを移動させられます。 ※vMotionはVMwareの用語です。一般的には、仮想マシンを無停止で別ホストに移動することをライブマイグレーションといいます。 なお、DRSはvCLSの登場と同時に、DRSの動作のためにはvCLSが有効であることが必須となっています。 ※参考サイト３ DRSによってクラスタのリソースを適切に配分することが可能となる。 DRSの動作にはvCLSが必須。（vSphere 7.0 Update 1以降） ※参考サイト３ 参考サイト３： https://techdocs.broadcom.com/jp/ja/vmware-cis/vsphere/vsphere/8-0/vsphere-resource-management-8-0/creating-a-drs-cluster.html#GUID-CAF3CDC4-469F-4FA4-ACFD-24F5F36847EA-en （DRS クラスタの要件） その他参考サイト： https://techdocs.broadcom.com/jp/ja/vmware-cis/vsphere/vsphere/8-0/vsphere-resource-management-8-0/creating-a-drs-cluster.html （vSphere DRSクラスタの作成）   HA (High Availability) とは独立 HAとは、「クラスタ内のESXiホスト停止時に、停止したESXiホストで稼働していた仮想マシンを別ホストで自動的に再起動する機能」です。 以下はイメージ図です。 図の説明をします。 はじめに3台のESXiホストそれぞれで3台づつVM（仮想マシン）が稼働している状況で、一番右のESXiホストが突発的に何らかの障害で停止したとします。 この時、HAの機能によってホストの停止を検知し、停止したESXiホストで稼働していた3台のVMを残り2台のESXiホスト上で再起動します。 HAはDRSとは異なり、動作のためにvCLSは必須というわけではありません。 ただ、VMを再起動する際に、どのESXiホストで起動するかを適切に選択するためには、DRSの動作が必要になっています。 ※参考サイト４ HAによってESXiホストの障害発生時にVMが自動で再起動される。 HAの最適な動作のためにはDRSが必須であり、DRSの動作のためにはvCLSが必須。 ※参考サイト４ 参考サイト４： https://techdocs.broadcom.com/jp/ja/vmware-cis/vsphere/vsphere/8-0/vsphere-resource-management-8-0/vsphere-cluster-services-vcls.html#GUID-F98C3C93-875D-4570-852B-37A38878CE0F-en （クラスタの退避モードへの切り替え） その他参考サイト： https://techdocs.broadcom.com/jp/ja/vmware-cis/vsphere/vsphere/8-0/vsphere-availability/creating-and-using-vsphere-ha-clusters/vsphere-ha-interoperability/using-vmware-ha-and-drs-together.html （vSphere HA と DRS の併用）   vCLSの構成 ここではvCLSの実態について説明します。 最初に述べたようにvCLSは仮想マシンとして稼働しています。 vCLS仮想マシンの数 以下はイメージ図です。 図を説明します。 Cluster①、②：3台以上のESXiホストによって構成されるクラスタでは、vCLS VM（vCLS仮想マシン）は3台以上存在し、それぞれ別々のホストに配置されます。 Cluster③、④：クラスタのESXiホストの台数が3台より少ない場合は、ホストと同じ台数のvCLS VMが存在し、同じくそれぞれが別のホストに配置されます。 ※vCLS仮想マシンは、手動の移動や、HAによって一部のESXiホストに偏ることがあります。 その対策として、3分ごとにチェックが行われ、自動的に複数のESXiホストに分散配置される仕組み（非アフィニティポリシー）があります。 ※参考サイト１ vCLS仮想マシンの数はクラスタのESXiホストの台数によって異なる。   vCLS仮想マシンのスペック vCLS仮想マシンは管理のためのVM（仮想マシン）であるため、ESXiホストのリソースを必要以上に使用しないために非常に軽量です。 具体的なスペックは以下の表のとおりです。 ※参考サイト５ プロパティ サイズ CPU 1 vCPU メモリ 128 MB ハードディスク 2 GB VMDKサイズ 245 MB（シンディスク） データストア上のストレージ 480 MB（シンディスク） 参考サイト５： https://techdocs.broadcom.com/jp/ja/vmware-cis/vsphere/vsphere/8-0/vsphere-resource-management-8-0/vsphere-cluster-services-vcls.html#GUID-E39875F2-2DA6-4592-A220-6014F54858D3-en （vSphere クラスタ サービスの監視）     vCLSの今後 ここでは新しいvCLSである、「組み込みvCLS」について説明いたします。 vCLSには現在、「外部vCLS」と「組み込みvCLS」の2種類があります。 外部vCLSとは、これまでに説明してきたvSphere 7.0 Update 1以降で導入された従来のvCLSのことです。 組み込みvCLSとは、vSphere 8.0 Update 3以降で導入された新しいvCLSのことです。 どちらを使用するかはvCenterのバージョンによって決定されます。 組み込みvCLSは従来の仮想化による管理ではなく、コンテナとして管理されるようになり、以前にもましてリソースの消費量が抑えられています。 ※参考サイト６ リソース消費の低下には、以下の2つの組み込みvCLSの特徴が関わってきます。 ESXiホストのメモリ内で直接実行される メモリ内で実行されるため、ストレージの占有量がゼロ その他の「外部vCLS」と「組み込みvCLS」の変更点としては、 クラスタ当たりのvCLS仮想マシンの数が2つ。単一のESXiホストによって構成されるクラスタの場合のみ、vCLS仮想マシンの数が1つ。 などがあります。 vSphere 8.0 Update 3からは「組み込みvCLS」という新しいvCLSが導入されている。 参考サイト６： https://blogs.vmware.com/vmware-japan/2024/12/vmware-vsphere-8-update-3-newfeatures.html （VMware vSphere 8 Update 3 の新機能 – VMware Japan Blog）   まとめ 今回の内容をまとめると以下の通りです。 vCLSはvCenterが一時的に停止した際に、クラスタの健全性を代わりに維持する機能。 DRSによってクラスタのリソースを適切に配分することが可能となる。DRSの動作にはvCLSが必須。 HAによってESXiホストの障害発生時にVMが自動で再起動される。 HAの最適な動作のためにはDRSが必須であり、DRSの動作のためにはvCLSが必須。 vCLS仮想マシンの数はクラスタのESXiホストの台数によって異なる。 vSphere 8.0 Update 3からは「組み込みvCLS」という新しいvCLSが導入されている。 今回の記事の執筆にあたりvCLSについて初めて知ったことも多数あるので、仕事に生かしていきたいと思います！

先日、Palo Alto Netwoks社より Cortex Cloudが発表 されました。 Cortex Cloudとはどのようなものか簡単に解説してみたいと思います。   Cortex Cloudとは？ Cortex Cloudは、「Prisma Cloudの次期バージョンとCortexプラットフォームのCDRを組み合わせたもの」と記載されています。 ここで少しPrisma CloudとCortexについても触れておきます。 簡単に説明するとPrisma Cloudはクラウドのセキュリティ保護プラットフォーム、Cortexは運用を強化する包括的なプラットフォームとなります。 Prisma Cloud：包括的なクラウドネイティブアプリケーション保護プラットフォーム（CNAPP）であり、コードからクラウドまでのセキュリティを提供。マルチクラウド環境にも対応。アプリケーションのライフサイクル全体を通じてリスクを排除し、リアルタイムでの脅威検出と防御を実現。 Cortex：サイバーセキュリティ運用を強化するための包括的なプラットフォーム。AIと自動化を活用して、脅威の検出、対応、予防を統合し、セキュリティオペレーションセンター（SOC）の効率を向上させる。 主要な製品として、Cortex XDR（脅威検出）、Cortex XSOAR（セキュリティオーケストレーション、自動化）、およびCortex Xpanse（攻撃対象領域管理）が含まれる。 つまり Cortex Cloud はクラウドセキュリティに対してAIと機械学習を活用して、リアルタイムで脅威を検出し、迅速に対応するセキュリティプラットフォームと考えることができます。   なぜCortex Cloudが必要なのか 現在、クラウドのインフラを攻撃から防御するのは非常に困難になってきています。 その背景にあるのがAIです。例えばフィッシングメールもAIにより、より高速に、よりパーソナライズされた仕掛けを作ることができるようになっています。その結果、侵入を防ぐことが困難になってきています。 また、攻撃者はクラウドを深く熟知し、攻撃のステップを高速に実行します。検知してから対策を実施するまでの猶予時間はどんどん短くなってきています。 かといって、すべてのアラートに対してリアルタイムに対応するのは現実的には不可能です。 そのため、Cortex Cloudのように リアルタイム脅威検出 ：AIと機械学習を活用して、リアルタイムで脅威を検出 自動化されたレスポンス ：脅威を検出すると自動的に適切な対策を講じ、セキュリティインシデントの影響を最小限に抑える 統合管理 ：ネットワーク、クラウド、エンドポイントのセキュリティを一元管理し、包括的なセキュリティ対策を提供 といった機能を提供し、セキュリティ負担の軽減、迅速な対応、コスト削減といったメリットを提供するツールが重要になってくるのではないかと思います。   まとめ クラウド環境がますます複雑化し、攻撃者の手法が高度化する中で、Cortex Cloudのようなツールは、セキュリティチームの負担を軽減し、迅速かつ効果的な対応を可能にします。これにより、企業は安心してクラウドの利便性を享受しつつ、セキュリティリスクを最小限に抑えることができるではないでしょうか。 また、クラウドセキュリティを行う上で重要なポイントして現状のクラウドセキュリティの可視化があります。まずは自身のクラウド環境がどのような状況にあるか確認することが非常に重要です。 当社ではクラウド診断のサービスを提供していますので、ご興味のある方は是非、お気軽にお問い合わせください。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp

企業ネットワークにおける情報の持ち出し対策として、 Data Loss Prevention(DLP) が広まりつつあります。 情報の持ち出しは、正規のアクセス権限を持った人によって行われることが多く、それ自体は異常な通信ではないためにEDRやIPSでは検知できません。これをカバーする機能がDLPで、機密情報等を含むファイルの動きを検知して、通知したりブロックすることができます。 しかしながら、実際にDLPを導入しようとすると「具体的にどう制御したらいいのか?」を決めるのが難しく、当社でもご相談を受けることが多いです。 そこでこの記事では、 実際に設定されることの多いDLPルールの例をご紹介します。 設定はSASEソリューションである「Catoクラウド」のDLP機能に沿ってご紹介しますが、他のDLP製品においてもルール検討の参考にしていただけましたら幸いです。 なお、CatoクラウドのDLP機能の概要や設定方法については、当ブログ内にいくつかの記事がありますので、あわせてご参照ください。 CatoクラウドのCASBとDLPについて CatoクラウドのセキュリティオプションであるCloud Access Security Broker （CASB）とData Loss Prevention （DLP）について解説しています。 blog.usize-tech.com 2024.02.19 CatoクラウドのDLPについて Catoクラウドの情報漏洩対策にあたる「DLP」について紹介していきます！ blog.usize-tech.com 2023.10.06 DLPではどんな制御ができる? DLPでは、 あらかじめキーワードやデータ形式を指定しておき 、それを含むデータのやり取りを検知して、 通信を止めたり、管理者へ通知する ことができます。これにより、例えば 「社外秘」という文言が入った資料をクラウドサービスにアップロードしようとしたら通信を止める 、といったルールの設定が可能です。 どのようなデータを止めたい(または監視したい)のかの条件は、自社の業務やポリシーに沿って検討する必要がありますが、この条件決めがなかなか難しいため、参考になりそうな例をご紹介します。   DLPのよくある設定例 対象ファイルの条件 まずは、どのようなファイルを制御の対象にしたいのかを指定します。 「社外秘」「関係者外秘」「Confidential」といったキーワードが入っているファイル 👉️機密情報を含むファイルに対し、上記のようなキーワードの記載ルールが徹底されている場合、それを条件としてデータの持ち出しを検知できます。 クレジットカード番号やマイナンバーを含むファイル 👉️個人情報の持ち出し対策として有効です。 Microsoft製品の「秘密度ラベル」がつけられたExcel、Word等のファイル 👉️Microsoftが提供する「秘密度ラベル」機能を運用されている場合、これをDLP製品でも活用できる場合が多いです。 Pass付zip等、暗号化されたファイル 👉️条件に一致する機密ファイルでも、パスワード付きのZipファイルなどの暗号化ファイルにしてしまえば、DLP製品が中をチェックできないために、持ち出せてしまいます。これを防ぐために、暗号化ファイル自体の持ち出しを禁止することができます。 以上が一般的な例ですが、自社のルールや業務内容から「どんな情報を社外に持ち出されると困るか」を考えてみると、使えるキーワードや条件が見つかるかもしれません。 制御ルール 次に、条件に一致したファイルをどうするかを決めます。以下のような例が考えられます。 アップロード・ダウンロードをすべてログに残す 👉️有事の際に後から確認できるようにしておく目的です。 インターネット上のクラウドサービスへアップロードしようとしたらブロックする 👉️持ち出しと疑われる通信は止めてしまうという設定です。 なお、最初から通信ブロックを設定すると、想定しなかった業務影響が発生する場合があるため、初めはログを残すのみとし、実際の通信状況を確認した上でブロックへの移行を検討されるようおすすめしています。 DLP設定の例 以下に、 条件とルールを組み合わせた設定例 をご紹介します。 「社外秘」「関係者外秘」「Confidential」 のいずれかのキーワードを含むファイルについて 自社テナントのOneDriveに対しては、制限なし その他すべてのクラウドサービスへは、対象ファイルの アップロードをブロック する その他すべてのクラウドサービスへは、対象ファイルのダウンロードはログに残す 👉️実際によくある設定です。社外秘情報の持ち出しを防ぐ意図です。 Eメールアドレスを30個以上含む ファイルについて すべてのクラウドサービスへのアップロード・ダウンロードをログに残し、 管理者へ通知 する 👉️Eメールアドレスを多く含むファイルは、個人情報リストの可能性があるため監視するという設定例です。 100MB以上のファイル について 自社テナントのboxに対しては、制限なし その他すべてのクラウドサービスへの アップロードをログに残す 👉️大きなサイズのファイルのアップロードは、データの持ち出しの可能性があるため、記録しておくという設定例です。 いかがでしょうか。このように実際のルールを見てみると、DLPでできることがイメージしやすいかと思います。 DLPは本当に有効なのか? ところで、DLPの設定をしっかりと行えば、情報の持ち出しは防げるのでしょうか? 答えは残念ながらNoです。 持ち出し方法は他にも無数にあります。例えば機密情報を表示した画面をスマートフォンで撮影したり、単純に手帳に書き写したり、やりようはいくらでもあり、全てを防ぐことはできません。 しかしながら、 DLPの導入には以下の効果があります 。 DLPで監視することで、持ち出しの一部に素早く気づける。早々に対処を行うことで、情報の拡散を防ぐことができる。 DLPのログを取っておくと、万が一情報流出が起こった場合にログから流出元を特定できる可能性がある。 DLPが導入されている旨を周知することが、持ち出しに対する抑止力となる。 DLPはそれ単独で完璧なソリューションではなく、 不正の”機会”を減らすための対策の一つ であるということに留意する必要があります。   CatoクラウドのDLP機能 最後に、CatoクラウドのDLP機能についてご紹介します。 CatoクラウドのDLPはオプションでのご提供となっており、ご利用にはCASBオプション+DLPオプションのご契約が必要です。また、TLS Inspection機能が有効になっている必要があります。 DLP条件 様々な方法での条件指定に対応しています。 プリセットのデータカタログ Catoにあらかじめ設定されていて、すぐに条件として使えるものです。 日本のマイナンバーや、世界共通のクレジット番号、世界各国のID形式などが収録されており、指定するだけで条件として利用することができます。 キーワード登録・辞書登録 自社専用のキーワードや、キーワード辞書を作成して利用できます。もちろん日本語にも対応しています。 正規表現 正規表現による文字列指定も可能です。 Microsoftの機密度ラベル M365と連携することで、ユーザ定義のラベルにも対応できます。 機械学習による条件作成 識別させたいデータを複数与え、学習させて条件を作成でききます。 Exact Data Matching 実際のデータを読み込ませて、それに完全一致するデータを見つける機能です。 例えば、従業員管理台帳をDLPエンジンに読み込ませて、実際の従業員番号と氏名の組み合わせを記録することができます。※データはハッシュ化されて安全にアップロード・保存されます DLPルール 条件に合致するファイルについて、各種クラウドサービスへのアップロード・ダウンロードを、許可・ブロック・ログに残すなど、柔軟なルール作成が可能です。 ユーザ単位やグループ単位でのルールや、接続元の国、端末の条件などに基づくルールも作成できます。 また、本記事で設定例としてご紹介したルールは、すべてCatoクラウドのDLP機能で実現可能な内容です。先程の例の1つめですと、以下の設定となります。 「社外秘」「関係者外秘」「Confidential」のいずれかのキーワードを含むファイルについて Security > Data Types & Profiles > Data Types > User Defined で Dictionaryを作成する Security > Data Types & Profiles > DLP Profiles で、上記のDictionaryを指定しプロファイルを作成する 自社テナントのOneDriveに対しては、制限なし Security >App & Data Inline にて、CASB機能で自社テナントのみ Microsoft Loginを許可する設定をする (参考) CASBの制御って何をしたらいいの? ～ルールの設定例 上記のルールよりも下に、OneDriveへのDownload/UploadをAllowするルールを設定する その他すべてのクラウドサービスへは、対象ファイルのアップロードをブロックする 上記のルールよりも下に、Any Cloud Applicationに対し、指定のDLP Profilesに合致するUploadをBlockするルールを設定する その他すべてのクラウドサービスへは、対象ファイルのダウンロードはログに残す 上記のルールよりも下に、Any Cloud Applicationに対し、指定のDLP Profilesに合致するDownloadをMonitorするルールを設定する Cato管理画面での実際の操作方法等につきましては、 Catoクラウドのナレッジベース  をご参照ください。 CatoクラウドのDLPの制約 Catoクラウドではこの制御をPoP上で行うため、以下のような 端末ローカルでの操作を制御することはできません 。 ❌️ 端末からUSBメモリへのコピーを禁止 ❌️ プリンタでの印刷を禁止 ❌️ スクリーンショットを禁止 また、ファイルサイズやファイルタイプ等によりDLPの動作に制約があります。こちらも詳しくは Catoクラウドのナレッジベース をご確認ください。   最後に 本記事を通して、DLPの活用イメージを持っていただけましたら幸いです。 また、CatoクラウドのDLP機能は、現在も鋭意機能拡充中です。こういった制御はできる?など導入・運用のお悩みがありましたら、ぜひSCSKへご相談ください。

こんにちは　ＳＣＳＫ　池田です。 ３月に入り、桜の開花が待ち遠しい季節になりましたが、すでにお花見の予定を立て始めている人もいるとか。なかなか気が早いですね　笑 さて今回は、ちょっと解りづらいLifeKeeperのプロダクトライフサイクル（サポート）について解説したいと思います。 サポートレベルのフェーズは大きく３つに分けられる LifeKeeperのサポートフェーズは、大きく以下の３つに分けられ、「技術的な支援」や「不具合などの問題への支援」の内容が異なります。 ※細かく分けると「ライフサイクル年長プラス」というフェーズもありますが、説明を簡単にする為、本ブログでは３つについて解説します。   サポートフェーズ サポート内容 1 フルサポート 未知の 製品不具合に対するパッチを作成し提供する 2 メンテナンスサポート 既知の 不具合に対するパッチを提供する。 本フェーズ以降に発見された未知の不具合については最新バージョンへのアップデートを案内する。 3 ライフサイクル延長 標準のサポート契約に加えて、 「ライフサイクル延長サポート」もご契約いただいた際 に、メンテナンスサポートと同レベルのサポートを提供する ※ユーザーポータルからのお問い合わせに対しての回答となります。 それぞれのフェーズ毎の「技術支援」「不具合などの問題への支援」に関してサポートされる内容の違いは上記の通りですが、このほかにも以下のサービスが提供されます。 ・ライセンスアカウントの再発行　※ライセンスシステムのログインID再発行、バージョンアップ手順の案内を含む ・バージョンアップ版の無償利用   これらを整理すると以下のマトリクスで表現できます。   サポートフェーズ ライセンスアカウント再発行 バージョンアップ版の無償利用 技術支援/問題対応支援 不具合パッチの利用 1 フルサポート 〇 〇 〇 〇 2 メンテナンスサポート 〇 〇 〇 ー 3 ライフサイクル延長 〇 〇 〇(※1) ー (※1)標準のサポート契約に加えて、「ライフサイクル延長サポート」もご契約いただいた際に、メンテナンスサポートと同レベルのサポートを提供する   サポートフェーズ期間はOSによって期間が異なります ご存じの通り、LifeKeeperにはLinux版とWindows版とありますが、 OSごとにサポートフェーズの期間とその考え方が異なります。 Linux版のサポートフェーズ期間 以下の表をご覧ください。 こちらはサイオステクノロジー社の公式サイト「プロダクトライフサイクル」の画面となりますが、Lifekeeper for Linuxの最新バージョンであるv9.9.0は、フルサポート終了日以降が決定していないことが判ります。 この理由は、Linuxのサポート期間の考え方が 次のアップデートリリース時が起点となる ためです。 一つ前のバージョンであるv9.8.1を例にすると判りやすいと思います。 以下のようにv9.8.1は2024年3月にリリースされていますが、この時点ではフルサポートの終了日が決まっていません。 そして2024年9月に次のアップデートリリースであるv9.9.0がリリースされました。 この時点で、v9.8.1のフルサポート終了日が2027年8月末（v9.9.0のリリースから3年後）と定まるのです。 ■LifeKeeper for Linux v9.8.1のサポート期間   次のアップデートリリースが起点になるなんてユニークな考え方ね Windows版のサポートフェーズ期間 では、Windows版のLifeKeeperのサポートフェーズ期間はどうなるのでしょうか？ Linux版と異なり、最新バージョンのLifeKeeper for Windows v8.10.2のフルサポート終了日が既に決まっています。 従いまして、以下のように 当該バージョンのリリース時点で、フルサポート期間、メンテナンスサポート期間、ライフサイクル延長期間の終了日が確定 しています。 Windows版は「ライフサイクル延長期間」が短い Windows版の場合、もう一点注意が必要なのが「ライフサイクル延長期間」が2年と短い という点 です。Linux版とWIndows版のライフサイクルを並べてみました。Linux版の場合は5年のライフサイクル延長期間が設けられています。 特に Linux版 と Windows版の混在 するシステム では、ライフサイクル延長期間の違いを十分に理解した上で、 「Windows版のライフサイクル延長期間の費用を見込んでなかった」 ということがないように気を付けましょう。   LifeKeeperの次期バージョンに期待！ ここまでご説明したとおり、LifeKeeperはLinux版とWindows版で、サポートフェーズの考え方も期間も異なります。 これは製品開発の歴史などの背景によるものと思われますが、これにより少なからず誤解や混乱を招いている部分もある為、LifeKeeperの次期バージョンv10では、「LifeKeeper」という統一的な考え方にもとづいた製品開発に期待したいものです。   まとめ 今回は、LifeKeeperのサポートフェーズについて解説しましたが、いかがでしたでしょうか？ まとめると、、、 ・サポートフェーズは主に3つ（フルサポート、メンテナンスサポート、ライフサイクル延長） ・OSによりサポート終了の考え方が異なる ・Windows版の、ライフサイクル延長は2年と短い ・次期バージョンにおける製品サポートに関する考え方の統一に期待

こんにちは。SCSKの山口です。 今回は、Google Cloud認定資格の受験レポート その①です。 はじめに 先日、Google CloudのAssociateレベルの認定資格として、下記二つの認定資格が追加されました。 ・ Associate Data Practitioner ・ Associate Google Workspace Administrator 全冠維持継続中の私にとっては見逃せないニュースでしたが、 Associate Google Workspace Administrator に関しては、前身となるProfessional Workspace Administrator を取得済みであれば有効期限が切れるまでは何とかなるようです。 問題は「 Associate Data Practitioner 」です。 情報収集として、社内で受験済みの人がいないか探し回っていますが、本ブログ執筆時点で見つけ切れず、なんとか自力で対策するしかなさそうです。。。というわけで、今日から対策を始めようと思ったのですが、「せっかくだから受験前後でブログ書いてみよう」と思いつき、今日から執筆を始めました。 受験前後のブログではそれぞれ下記を書こうと思っています。 [受験前] ・対策内容 ・抑えておく要点 [受験後] ・合否 ・出題内容（受験前の想定とのギャップ） ・抑えておいた方が良い要点 本ブログ執筆時点の筆者はこんな感じです。 Google Cloud歴 3年目 BigQuery一番よく触っている Professional Data Engineer取得済み 最新のTOEICスコア：645（※試験が英語版しかないので書きました。）   対策内容 ここでは、受験前に実際に取り組んだ対策の内容を書きます。 とりあえず試験ガイドを見てみる 試験ガイドは、認定資格ページにリンクが貼ってあります。 https://services.google.com/fh/files/misc/v1.0_associate_data_practitioner_exam_guide_english.pdf?hl=ja 英語があまり堪能ではないので、PDFでダウンロードして「 NotebookLM 」にアップして日本語で読みました。 ドキュメントをほとんど翻訳しただけの内容を書きますが、あまり深読みせず、「こんな感じのが問われるんだな。」と大まかな内容を把握するために使いました。   ①データ準備と取り込み（～30％） このセクションでは、その名の通り「データの取り込み～利用可能な状態にするまでのプロセス」に焦点が当てられています。 データ処理方法（ETL,ELT,ETLT）の理解と適切な選択 データ転送ツールの適切な選択 データの品質評価とクレンジング データ形式の識別とストレージ選択 この辺りが問われるそうです。   ②データ分析とプレゼンテーション（～27％） このセクションでは、データの分析、可視化、機械学習モデルの活用に関する知識とスキルに焦点が当てられます。 BigQueryとJupyter Notebookを用いたデータ分析 Lookerを用いたデータ可視化とダッシュボード作成 機械学習モデルの定義、トレーニング、評価、利用 この辺りが問われるそうです。   ③データパイプラインのオーケストレーション (~18%) このセクションでは、データパイプラインの設計、実装、自動化、監視に関する知識に焦点が当てられます。 適切なデータ変換ツールの選択 ELTとETLの使い分け データ処理タスクのスケジュール、自動化、監視 イベントドリブンデータ取り込みの活用 この辺りが問われるそうです。 「ELTとETLの使い分け」に関しては、①のデータ処理方法と重複しているように見えますが、ここでは ETLとELTのユースケースを評価した上での適切な選択 が求められるようです。   ④データ管理（～25％） このセクションでは、アクセス制御、ライフサイクル管理、高可用性と障害復旧、セキュリティ対策とコンプライアンスなど、データ管理の重要な側面に焦点が当てられます。 アクセス制御とガバナンス ライフサイクル管理 高可用性と障害復旧 セキュリティ対策とデータプライ バシー規制への準拠 この辺りが問われるそうです。 とりあえず模擬試験を受けてみる 模擬試験は、認定資格ページにリンクが貼ってあります。 Associate Data Practitioner Sample Questions The Data Practitioner sample questions will familiarize you with the format of exam questions and example content that m... docs.google.com 試験の詳細な内容はここには載せませんが、正解率は12/20でした。（まずい、、、） 英語なのもあり、ちょっと難しく感じます。 ここまでの内容をふまえ、受験前に抑えておいた方が良いと思われる（実際に学習した）内容を書きます。   抑えておく要点 試験ガイドと模擬試験の内容を加味し、試験前にこれだけは押さえておこうと思っている内容を書きます。 ETL/ELT で登場するサービス 本試験には、ETL/ELTを実現するために使用する多くのサービスが登場しそうです。 登場しそうなサービスと特徴、ユースケースを私がわかる範囲でまとめます。 サービス名（元名称） 機能概要 特徴・ユースケース Dataflow（Apache Beam） 大規模なデータ処理パイプラインを構築・実行するための フルマネージドサービス データの検証とクリーニング リアルタイム処理とバッチ処理を どちらも処理可能 低レイテンシ オンプレミス、Google Cloud内どちらのソースデータにも対応可能 スケーラビリティ 処理頻度にバラツキがある際にも有効 データ品質 の問題を解消 Dataflowテンプレート： ユーザ定義関数（UDF） で機能拡張が可能 Dataproc（Apache Hadoop、Apache Spark） Apache Hadoop および関連エコシステムをクラウド上で実行するための マネージドサービス 他サービスとの連携が容易 大規模な並列処理 が可能 Dataprocサーバレス：インフラ管理が不要 Dataprocワークフローテンプレート：ジョブ管理とスケジュール管理に特化。メール通知機能もあり Data Fusion コード不要でデータ統合・変換処理を構築するためのクラウドネイティブETLサービス 他サービスでは対応が難しい 複雑な処理 （入力ファイルの解析等）が必要な際に最適 多様なデータソースに対応 GUIで直感的に パイプライン構築 コーディング不要 Cloud Composer（Apache Airflow） 複雑なワークフローを定義・管理するフルマネージドワークフローオーケストレーションサービス DAG （有効非巡回グラフ）をPythonで記述 複雑なワークフロー をカバー スケジュール 機能 再試行ポリシー で失敗したタスクを監視＋再実行 各フローの 依存関係の管理 が可能 試験で特に重要になりそうなのが、 「元名称」 と 「特徴・ユースケース」 です。 元名称は、例えば、「 Apache Hadoopの処理を移行したい 」など、移行元のワークフローが特定されているような問題の際に使えます。この場合は「 Dataproc 」を使用している選択肢に絞り込むことができます。 元名称で特定できない場合に、「特徴・ユースケース」の知識を使います。問題文中の要件に合わせてサービスを選択できます。 ETL/ELTの使い分け 模擬試験の内容を見る限、割と明確に処理の順序が記載されている（Loadする前にTransformしたい。とか）ので、軽く表にまとめます。 方式 処理順序 メリット デメリット ETL 抽出 → 変換 → ロード データ品質確保 DWH負荷軽減 柔軟性欠如 変換処理に時間かかる ELT 抽出 → ロード → 変換 柔軟性高い リアルタイム分析 DWH負荷増大 データ品質管理が必要 Data Fusionを使うかどうか 試験問題を解く際、数を熟していくと 「これはData Fusion使う必要あるのか、、、？（スケジュールクエリとかで事足りるのか、、、？）」 という分かれ道に立つことが多くなると思います。 その際に使える判断基準の例を書いておきます。 ・複雑なデータ変換処理が必要か？ ・データソースはどこか？（BigQuery or その他） ・問題に登場するユーザのスキルは？（SQLに精通、開発経験がない、GUIで開発したい、など） 「複雑なデータ変換」かどうかは抽象的過ぎてこれ以上明確な切り分けが難しいですが、複雑な変換の場合、複雑さが問題文の表現からプンプン匂ってくるような表現がされている場合が多いです。 具体的な処理で言うと、 ・NULL値の排除 ・ 重複排除 ・データフォーマット統一 くらいであれば、BigQuery上でクエリ実行したほうが手っ取り早いです。 BigQuery BigQueryは他試験でもかなり多く目にするGoogle Cloudの目玉サービスの一つですが。本試験でもかなり多くの問題に登場しそうです。 模擬試験の出題内容から、抑えておいた方が良いと思われる項目を書きます。   アクセス制御 BigQueryのアクセス制御は、ユーザに行わせる（許可する）アクションに合わせて下記ロールを付与する必要があります。 許可する処理 必要なロール データ閲覧（読み取り） BigQueryジョブユーザ BigQuery閲覧者 データ編集（読み取り＋書き込み） BigQueryジョブユーザ BigQuery編集者 SELECTのようなデータの閲覧しか行わないユーザには「閲覧者」 UPDATEのようなデータの編集を行うユーザには「編集者」を付与する必要があります。 また、上記どちらのユーザも 「クエリの実行」 は行うので、 「ジョブユーザ」 を付与する必要があります。   暗号化 Google Cloud内のデータは、基本的に Googleが管理する暗合鍵（GMEK） で デフォルトの暗号化 がされています。 一方で、暗号化に 顧客管理の暗号鍵（CMEK） を使用することもできます。CMEKを使用することで、複雑な暗号化要件に対応することもできます。詳細は 公式ドキュメント をご参照ください。 似た用語で、 顧客提供の暗号鍵（CSEK） があります。CSEKは顧客がGoogleのインフラストラクチャ外で暗号鍵を管理できるため、 Googleから暗号鍵にアクセスされたくない ような厳格な規制要件がある際に使用されます。 本試験では、GMEK、CMEK、CSEKに加えて「 認証付き暗号化（AEAD） 」も取り扱われるようです。 AEAD 暗号化関数を使用すると、暗号化と復号に使用する鍵からなる鍵セットを作成し、これらの鍵を使用して テーブル内の個々の値を暗号化および復号 できます。 たとえば、BigQueryテーブルの列レベル、行レベルで暗号化を適用する。みたいな使い方が可能です。   パーティショニング BigQueryには、日時のカラムでデータを論理的に分割するパーティショニング機能があります。詳細は過去ブログをご覧ください。 【GCP】BigQuery -パーティショニングによるコスト削減- BigQueryでの「テーブルの論理パーティション分割の有効性」についてご紹介します。 blog.usize-tech.com 2023.04.04 本試験では、パーティショニング機能を活用したGoogle Cloud内でのデータの整理が出題されるようです。たとえば、下記のような要件、実現方式があります。 [要件] ・BigQueryに分析用のデータをため込んでいる ・最初の一年間は分析に利用される（頻繁にクエリされる） ・一年経過後は、長期保管に切り替える [実現方式] ・BigQueryをパーティション分割する（月単位） ・一年経過後にCloud Storageへエクスポートする このようにしてデータを順次移動させていくことで、コストを抑えたデータ管理を実現することができます。 また、長期保管用のCloud Storageのストレージクラスを要件に合わせて選択することでよりコストパフォーマンスを高めることができます。（詳細は後ほど書きます。）   公開データセット BigQuery には 一般公開データセット と呼ばれる一般提供のデータセットが用意されています。 世界の気象データ 国勢調査データ（アメリカ） 小売店の販売実績データ など、様々な種類のデータが大量に用意されており、なんと Googleがこれらの保存費用を負担 してくれています。 我々ユーザは、これらのデータへアクセスし、様々な用途に使用することができますが、もちろん「クエリ料金」は発生します。 むやみにエクスポートやコピーをしてしまうと膨大な料金が発生してしまう恐れがあるので、必要に応じて 「参照」だけ を行うことが推奨されます。   Cloud Storage これまた他試験でも馴染みのあるサービスですが、知識が必要になりそうなところがあるので説明します。 冗長化と高可用性 GCSのデータの冗長化、高可用性を実現する方式は、下記の二つがあります。 マルチリージョン デュアルリージョン かなり似た概念で、混乱すると思うので下記表でまとめます。どちらも、複数のリージョンにデータを複製する手法です。   マルチリージョン デュアルリージョン データの場所 複数の大陸にまたがる2つ以上のリージョン 例）アジアとヨーロッパのリージョン 特定の2つのリージョン 例）アジア内の二つのリージョン 可用性 非常に高い（広範囲な障害に対応） 高い（リージョンレベルの障害に対応） レイテンシ グローバルアクセスに最適 特定の地域へのアクセスに最適 コスト 高 （マルチリージョンと比較すると）低 ユースケース グローバル、ミッションクリティカルなアプリケーション リージョンレベルの障害対応、地域特化型アプリケーション、データ所在地規制   ストレージクラス Cloud Storageには ストレージクラス と呼ばれるオプションがあり、 保存するデータの性質によって適切な選択 をすることでコストパフォーマンスを最大化することができます。 BigQueryの章で紹介したパーテイショ二ングと組み合わせることで、 要件に合わせた高コスパなデータ保管 が実現できます。 また、オブジェクトに対する操作の状況に応じて自動的にストレージクラスを設定することができる「 オートクラス機能（Autoclass） 」といった便利なものも存在します。 各クラスの概要は下記のとおりです。 ストレージクラス 最小保存期間 オペレーション料金 ストレージ料金（GB/月）※東京リージョン Standard なし なし $0.023 Nearline 30日 $0.01/GB $0.016 Coldline 90日 $0.02/GB $0.006 Archive 365日 $0.05/GB $0.0025   最小保存期間 Standard以外のクラスには「最小保存期間」が設定されています。 オブジェクトがバケットに保存された後、削除や移動を行った場合でも、各storageクラスで定められた最小保存期間分の料金が発生します。 例えば、Nearlineのバケットに保存したオブジェクトを10日後に削除した場合でも、30日分の料金が発生します。その分、 移動等をせず保存しておくだけなら料金が抑えられる ってことですね。   オペレーション料金 Standard以外のクラスには「オペレーション料金」が設定されています。 バケットに保存されたオブジェクトデータ（またはメタデータ）を読み取り、コピー、移動、書き換えする際に発生します。 長期保存（Archive）の予定だったけど、思いのほかオペレーションの対象になってしまった。となると、割高な料金が発生してしまいます。   データ転送ツール BigQuery Data Transfer Service（BDTS） BDTS は、あらかじめ設定されたスケジュールに基づいて BigQuery へのデータの移行を自動化するマネージドサービスです。 下記を使用することが可能です。 Google Cloudコンソール bqコマンドラインツール BigQuery Data Transfer Service API サポートされているデータソースの全容は 公式ドキュメント をご参照ください。Googleのサービス（Google広告、Youtubeなど）だけでなく、 AWSやSalesforce、Olacle のサービスのほか、オンプレミスからの転送もサポートしている点は把握しておく必要があります。   Storage Transfer Service（STS） STS を使用することで、オンプレミスや他ストレージサービスから、 Cloud Storage へのデータ移動をシームレスに行うことができます。 下記の特徴があります。 データ転送を自動化 ：手動プロセス、カスタムスクリプトが不要 大規模データ転送 ：ペタバイト単位のデータも移動可能 ネットワークパフォーマンスを最適化 ：シンプルさを求めるならマネージド転送。ルーティングと帯域幅を制御したいなら自己ホスト型エージェントを使用 移行ステータスの確認が可能 ：移行ステータスの詳細なレポートを取得可能   Transfer Appliance Transfer Appliance は、Googleアップロード施設に転送して安全にデータを保存できる大容量ストレージデバイスで、データはGoogleアップロード施設から Cloud Storage にアップロードされます。 実際には、下記手順で実施します。 Transfer Applianceをリクエスト：要件に適したアプライアンスを選択 データをアップロード：アプライアンスにデータをアップロード Transfer Appliance を返送：データアップロード完了後、アプライアンスを返送する Google がデータをアップロード：Cloud Storage バケットにデータがアップロードされる 代表的なユースケースとしては、下記が考えられます。 インターネット経由のデータ移動に 時間がかかりすぎる 場合 データ移動に使用できる 帯域が十分に確保できない 場合 オフライン でのデータ移動を行いたい場合 セキュリティ要件 が高い場合 Looker 模擬試験を解いて、一番驚いたのが「Looker」に関する出題です。 ここでは要点だけ書きますが、Lookerが初耳の方は 公式のドキュメント をご確認ください。 Lookerは、一言で言うと 「可視化ツール（BIツール）」 です。 LookML というモデリング言語を使用し、SQLデータベース内のデータを使って、ビジネスユーザーが理解しやすい形でデータ分析を行うための土台を作ります。   LookMLの主な要素 Lookerでは、Viewファイル内でDimensionとMajorを定義し、データを集計・分析します。 Explorer：ユーザが実際にでーあを探索、分析するためのインタフェースを定義する。 View：データベースのテーブルやビューを指す。分析の対象となるデータを定義する。 Dimension：分析の軸（観点）となる項目（日付、地域、商品名など）を定義する。 Major：集計、計算される値（売上、利益、顧客数など）を定義する。   Lookerでのアクセス制御 LookerではGoogle CloudのIAMと同様、ユーザを「グループ」でひとまとめにし、まとめて権限を付与することができます。 Google Cloud同様、Lookerにおいてもグループへの権限付与がベストプラクティスとされています。   まとめ いったん、ここまでの内容（＋これまでの知識）で試験挑んできます。 更新なかったら察してください、、、

本記事は 新人ブログマラソン2024 の記事です 。 皆さんこんにちは！入社して間もない新米エンジニアの佐々木です。 最近、Snowflakeの比較的新しい機能である「 コンピュートプール 」について調査する機会がありました。 そこで本記事では、コンピュートプールについて調べたことを皆さんと共有したいと思います！ 特に、公式ドキュメントに記載されている細かい内容というよりも、 コンピュートプールの概要について初学者でも分かりやすいようにお話できればと思います。 まだ触れたことのない方も、既に利用している方も、ぜひご覧ください！   コンピュートプールとは何か？ コンピュートプールとは、 1つ以上の仮想マシン（VM）ノードを複数集めたサーバー群 です。 分かりづらい方は「コンピューターの力を集めた場所」と考えてください。例えるなら、複数の人が集まって一つのチームとして働くようなものです。 仮想マシンとは、一台の物理コンピューターの中で動く、仮想的なコンピューターです。このVMをたくさん集めて、まとめて使えるようにしたものが、仮想マシンノードを集約したコンピュートプールです。 他にも似たクラウドサービスの代表例として、Amazon EC2、Google Compute Engine、Microsoft Azure Virtual Machinesなどがあります。 コンピュートプールの作成 では、実際にコンピュートプールを作成する際の手順についてですが至って簡単です。 コンピュートプールは CREATE COMPUTE POOL  コマンドを使って、ユーザーが自由に作成・管理することができます。 具体的には、ワークシートで以下のクエリを実行することで、コンピュートプールを作成することが可能です。 CREATE COMPUTE POOL tutorial_compute_pool MIN_NODES = 1 MAX_NODES = 3    　INSTANCE_FAMILY = CPU_X64_XS ; 上記で設定している必須プロパティの意味は以下の通りです。 MIN_NODES ：コンピューティングプールで起動する最小ノード数。 MAX_NODES ：コンピューティングプールがスケールできる最大ノード数。これにより、Snowflakeの自動スケーリングによって予期せぬ数のノードがコンピューティングプールに追加されることを防ぐことができます。 INSTANCE_FAMILY ：コンピューティングプールノードにプロビジョニングするマシンタイプ。 これらのプロパティをプロジェクトの規模やニーズに応じて変更することで、スケーラビリティの確保やコスト最適化などにつなげることができます。 他にも設定できるプロパティは複数あるのでプロパティの詳細について気になる方は、以下の公式ドキュメントを参照してみてください！ CREATE COMPUTE POOL | Snowflake Documentation コンピュートプールの利点 ではコンピュートプールの利点は何なのか？についてですが、私が調査した限りだと以下の5つが挙げられるかと思います。 柔軟なリソース管理： 複数のVMノードをプールとして管理できるため、ワークロードに応じて柔軟にリソースを割り当て、最適化できます。 コスト効率の向上： 個々のVMノードは必要な時に必要な分だけリソース（CPUやメモリ）を使います。そのため、使用していないVMノードを自動的にスケールダウンすることで、コストを削減できます。 高可用性の実現： プール内のVMノードに障害が発生した場合でも、自動的に別のVMノードに切り替えることで、高可用性を実現できます。 スケーラビリティ: ワークロードの負荷に応じて、VMノードを簡単に追加、削除をすることができます。これにより、ワークロードのピーク時でも、プール内のVMノードを自動的にスケールアップすることで、パフォーマンスを維持できます。 管理の簡素化： たくさんのVMを個別に管理するのは大変ですが、コンピュートプールを使うと、まとめて管理できます。VMの状態を監視したり、ソフトウェアをアップデートしたりするのが簡単になります。 特に上記で既述した「スケーラビリティ」について触れると、コンピュートプールは自動的にサイズ調整する自動スケーリングの仕組みを持っています。 まず、プールを作成すると、Snowflakeは最低限必要な数の仮想マシン（ノード）を起動します。その後、作業量が増えて現在のノードでは処理しきれなくなると、自動的に追加のノードを起動して処理能力を増強します。 例えば、既に2つのサービスが動いていて、新たに別のサービスを追加すると、そのサービスに必要なリソースに応じて自動的に新しいノードが追加されます。 逆に、ある期間、ノードがほとんど使われなくなると、Snowflakeは不要になったノードを自動的に削除してコストを削減します。そのような場合でも、コンピュートプールは最低限必要なノード数を維持します。 つまり、コンピュートプールは、作業量に合わせて自動的にサイズを調整し、常に最適なリソースを使用する仕組みになっているということです。ユーザーは、常に最大の処理能力を確保しつつ、無駄なコストを削減できます。 考えられる利用用途 コンピュートプールの利用用途として考えられるものを以下にいくつか挙げてみました。 1. データウェアハウス処理： 複雑なSQLクエリの実行： 大量のデータを集計、分析、変換するための複雑なSQLクエリを実行します。例えば、数年分の売上データを地域別、商品別に集計して、売れ筋商品を特定するような処理です。 大規模データセットの結合： 複数のテーブル（例えば、顧客テーブル、注文テーブル、商品テーブル）を結合して、より詳細な分析を行います。 高度な分析： データ分析に必要な高度なSQL関数（例えば、移動平均、累積和、順位付け）を実行します。 2. データエンジニアリング： ETL/ELTパイプラインの実行： 外部システムからデータを抽出（Extract）、変換（Transform）、ロード（Load）するプロセスを実行します。 データ変換： データをクレンジング、整形、標準化し、分析しやすい形に変換します。 データ検証： データの品質を維持するために、データの整合性や正確性を検証します。 3. ビジネスインテリジェンス（BI）: BIツールとの連携： Tableau、Power BI、LookerなどのBIツールからSnowflakeに接続し、データを可視化するためのクエリを実行します。 ダッシュボードの作成： 重要なビジネス指標を監視するためのダッシュボードを作成します。 レポートの生成： 定期的なレポートを生成します。 4. データサイエンス/機械学習： 特徴量エンジニアリング： 機械学習モデルのトレーニングに必要な特徴量をデータから抽出します。 モデルのトレーニング： Snowflakeのデータを活用して、機械学習モデルをトレーニングします。 モデルのデプロイと予測： トレーニング済みのモデルをSnowflakeにデプロイし、新しいデータに対する予測を行います。 リアルタイムデータ分析： ストリーミングデータソースからリアルタイムに近い形でデータをSnowflakeにロードし、分析します。 他にも利用用途は複数あるとは思いますが、上記だけでもコンピュートプールが様々なユースケースで役立ちそうなことが分かるかと思います。 まとめ 本記事では、Snowflake のコンピュートプールについて大まかな概要を調査しました。 その結果コンピュートプールは、複数の仮想マシンノードを束ね、クエリ実行やデータ処理といったワークロードを処理するための強力なリソースだと感じました。ただし、コンピュートプールを効果的に利用する上では、ワークロードの特性をよく理解し、適切なサイズと構成を選択することが何よりも重要だと思いました。 しかし、今回の調査だけではコンピュートプールの表面しか見ることができなかったのが実状です、、、 そのため今回の調査を踏み台に、次回以降で実際にコンピュートプールを活用したチュートリアルを実施して、コンピュートプールとは何ぞや？をもう少し深ぼってみたいと思います！

本記事は 新人ブログマラソン2024 の記事です 。 こんにちは。SCSKの さとです。2025年がもう6分の1が終わろうとしていることに愕然としています。 さて、2月にAmazon Bedrock Flows新機能のエージェントノードにおけるマルチターン会話がプレビュー公開されたので、今回はその「やってみた」記事です。 アップデートの概要   Amazon Bedrock Flows がマルチターンの会話サポートのプレビューを発表 - AWS AWS の新機能についてさらに詳しく知るには、 Amazon Bedrock Flows がマルチターンの会話サポートのプレビューを発表 aws.amazon.com Amazon Bedrock Flowsは、基盤モデルやプロンプト、Amazon Bedrockエージェントなどを ノードとして扱い 、 GUI上で相互に関連付ける ことで生成AIワークフローを簡単に構築できるようになるというサービスです。 今回のアップデートでは、エージェントがタスクを行うにあたり、必要に応じてフローを停止し、会話の往復の中で情報を取得しタスクを完了することが可能になりました。これにより、アクションの完了のために追加の情報取得が必要になった場合でも同一フローを用い続けることができず、エージェントがコンテキストを忘れてしまうという問題が解消されるようになります。   やってみた：企業の情報取得ボットの作成 というわけで、早速アップデートされたAmazon Bedrock Flowsのマルチターン会話を試してみたいと思います。 今回は、社員番号によって給与の額が決まる架空の企業「Exploitation Inc.」に関する情報を答えるチャットボットという設定でフローを組んでみます。このため、給与に関する質問を投げかけられると、チャットボットは社員番号について情報提供を依頼する必要があります。 Amazon Bedrock Flowsに触れるのは今回が初めてということで、本筋とは離れますが条件分岐を用いた複数種類のクエリへの対応も試してみました。フロー構成は以下の公式ブログを参考にしています。 Introducing multi-turn conversation with an agent node for Amazon Bedrock Flows (preview) | Amazon Web Services Today, we’re excited to announce multi-turn conversation with an agent node (preview), a powerful new capability in Flow... aws.amazon.com 処理の流れ ご覧のように、全体としてはFlow inputからユーザーの入力が各ノードに渡され、最終的にFlow outputへ到達したデータがレスポンスとなります。今回は、ユーザーからの質問をざっくりと「給与関係」「それ以外」に分け、それぞれで回答を行うようフローを作成しました。主要なノードの役割とその設定は以下の通りです。   Promptノード: QueryClassifier Promptノードは、フロー内で基盤モデルにプロンプトを送信し、その応答を取得するために使用することができます。ユーザーからの入力（Flow Inputの出力）はこのノードが受け取り、質問の内容に応じて分類されます。プロンプトはBedrockのプロンプト管理機能からのプロンプトを用いることもできますが、ここではノードで新たに定義しました。 {{input}}を分析し、ユーザーからの質問が給与に関する事項ならばAを、それ以外ならばBを出力してください。出力は必ず1文字であり、それ以外は受け付けられません。 ここで、{{input}}は入力に対してデフォルトで割り当てられている変数名で、上のように波括弧で括ることで指定できます。また、回答の信頼性を高めるため、出力の温度は低めの0.1に設定しました。   Conditionノード: QueryType Conditionノードでは条件の判定結果に応じて次の処理を行うノードを指定することができます。 QueryClassifie r のOutputから QueryType のInputまでを線で接続することで入出力関係を指定し、分かりやすさのため、さらにこの入力にQueryTypeという名前をつけます。 次に、条件とその分岐先を指定します。 QueryClassifier において入力が「給与関係」ならば出力がA、「それ以外」ならばBと指定したので、条件式を QueryType==”A” とし、これが真ならば次のノードとして AboutSalary へ、そうでなければ AboutOtherTopics へ移るよう設定を行います。       Agentノード： AboutSalary 、 AboutOtherTopics 分岐先のAgentノードを設定します。ここでは、作成済みのBedrockエージェントに対して入力を送信する処理が行われます。 ユーザーからの入力をもとに回答を作成するので、Flow Inputから各AgentノードのInputまでを接続します。ここで、フローのダイヤグラムにおいて紫色の点線で示されるConditionノード-Agentノード間の接続はあくまで処理の分岐を表すだけで、 入出力関係を表している訳ではない ということに注意が必要です。 また、これらのノードに紐つけるBedrockエージェントを別途作成・準備します。給与に関して応答を行うエージェントには以下のプロンプトを与えました。 あなたは、ユーザーから受け取ったExploitation Inc.の給与に関する質問に回答します。 回答にあたり、以下の事実を用いてください。 <ルール> 給与は、社員番号のみによって決定する。 社員番号 1〜10000: 年収1億円 社員番号 10001〜: 年収0円 給与以外に関して応答するエージェントも同様に設定します （このエージェントはマルチターン会話とは関係がないので、プロンプトは割愛します） 。 それぞれをFlow Outputノードへと接続し、ユーザーへの返答にします。 フローをテストする 一通りの設定が完成したので、フローの設定画面右側からテストをしてみましょう。 給与を確認すると、上のように追加で社員番号を聞かれました。エージェントへのプロンプトは追加で確認をさせるような文言が入っていないので、デフォルトでこのような指示が組み込まれていると考えられます。 続いて、社員番号を与えてみます。 給与に関して回答してくれませんでした。よく見ると、1回目の質問への返答があった直後に「 Flow ended in 45 seconds 」とフローが終了していることが示されており、そのまま社員番号の情報だけ渡したためその他の質問として扱われてしまっているようです。 どうやら、追加の情報取得を行うにはBedrockエージェント側で「ユーザー入力」を有効にする必要があったようです。その他の設定からオプションを有効にし、改めて試してみます。 謎に謝られてしまいましたが、想定通りの回答になりました。一応、社員番号 1〜10000でも指定した回答になるか試してみましょう。 無事、年収が1億円になりました。今回は簡単のためにプロンプトに直接情報を入れてしまいましたが、実際の場面ではエージェントを通してナレッジベースから情報を取得するなどが可能です。   おまけ：その他の話題に関する質問 せっかくなので、もう一方の条件分岐先であるその他の話題についても適切に回答されるか試してみましょう。 こちらも、あらかじめ設定した通りの内容が回答されました。   おわりに いかがでしたか？これまでだと不足する情報に対し情報提供を求めるには処理フローを追加する必要がありましたが、今回のアップデートではそのような部分がBedrock側で自動化されるため、かなりシンプルに実装が可能になったのではないかという印象を持ちました。 最後までお読みいただき、ありがとうございました。

SCSKの畑です。 以前のエントリ で少し触れた通り、Redshift テーブルのデータメンテナンスアプリケーションの実装にあたり、テーブルデータの表示や編集に使用したライブラリの Tabulator について、使用した理由や特徴をまとめてみました。このため、今回は完全にアプリケーション実装に閉じた話題となります。 なお、Tabulator の公式 URL は以下の通りです。 Tabulator - Interactive JavaScript Tables Create interactive data tables in seconds with Tabulator. A free, open source, fully featured JavaScript table / data gr... tabulator.info   ライブラリの要件及び選定理由 本案件事例における期間や工数の関係から、全ての機能を自前で作り込むのは難しいと考えていました。特に、テーブルデータの表示/編集については主要機能であり、かつ画面/ロジック両方の実装が必要になることから、できるだけ（出来の良い）外部ライブラリを使用しつつ必要に応じて手を加えるような形で進めるのが理想と考えていました。 ライブラリの選定における要件をまとめると、概ね以下の通りです。 ソフトウェアライセンスの観点で問題なく使用でき、かつ費用がかからないこと テーブル（表）形式のデータの表示及び編集機能を備えていること テーブル（表）形式のデータの表示及び編集のどちらについても基本的な機能を備えており、かつ必要に応じて拡張できること Nuxt(Vue) に対応していること（実装例があること） Web 上のドキュメントやナレッジがある程度充実していること で、平たく言うとこのような要件を満たすものとして一番筋が良さそうだったのが Tabulator でした。 まず、当時私が探した限り、1.及び2.を満たすライブラリがほとんど見当たらなかったのが一番大きな理由です。テーブル（表）形式のデータの表示のみであれば多種多様なライブラリがありましたが、いわゆるエクセルライクにテーブルデータを編集できるようなライブラリとなると数が大分限られました。その限られた選択肢においても出来の良さそうなものは表示機能のみなら無償だが編集機能を使用する場合は有償にとなったりしたため、この時点で実質的にはほぼ Tabulator の一択であったというのが正直なところです。 表示機能のみライブラリを使用し、編集機能（画面）は自前で実装する or 他のライブラリを活用するというアプローチも可能だったと思いますが、メンテナンス対象のテーブルやテーブル定義が変わり得る以上、各テーブルごとに編集画面を作成するのはコストや運用の観点から現実的ではありませんでした。各テーブルに拠らない汎用的な編集画面を作ろうとするとそれはそれでコストがかかる上、お客さんの画面イメージとしてもエクセルライクにテーブルの項目をそのまま編集できることが望ましいとのことで、やはりこのライブラリが良さそうだなと。 このため、3.以降は実質的にオマケというかあったら嬉しいな程度の内容だったのですが、それらの要件も満たしていたため最早このライブラリを選ばない理由がないと判断できました。 もちろん全てのライブラリを網羅して探すことはできなかったと思うので、もし他に良さそうなものがあればご教示頂けますと幸いです。それなりに気合を入れて探したつもりではあるので、簡単に見つかってしまったらちょっとショックかもしれないですが・・w   ライブラリで特に役立った・あって良かった機能 使用方法や各機能については公式ドキュメントの出来が良いため本エントリでは割愛し、ここではアプリケーション実装において特に役立った、あって良かったと感じた機能について簡単に所感を述べていこうと思います。 現時点で最新バージョンが 6.3 であるため、公式ドキュメントへのリンクは全て同バージョン向けとなっています。 Tabulator - Documentation Create interactive data tables in seconds with Tabulator. A free, open source, fully featured JavaScript table / data gr... tabulator.info   検索（フィルタ）/ ソート / ページネイト いずれの機能もテーブルデータの表示機能において標準的に求められる機能だと思うのですが、これらの機能が全て標準で備わっていたのが良かったです。（最も、このような機能は他ライブラリでもある程度備わっていたものが多かったので、そこまで特筆すべきことではないのかもしれませんが・・） Tabulator - Filtering Data Use custom or built in filter fuctions to allow users to view a subset of table data tabulator.info Tabulator - Sorting Data Allow users to order table data with a range of built in and custom sorter functions tabulator.info Tabulator - Pagination Break data down into pages to make it easier to digest tabulator.info また、後述する項目とも共通しますがこれらの標準機能は細かな設定変更が可能なものが多く、これらの機能については完全にライブラリの標準機能のみで賄えたという点も良かったです。例えばエクセルの列フィルタライクな検索機能や、テーブル画面初期ロード時のソート条件指定、ページネイトにおける1ページあたりの件数指定の動的な変更などですね。   ローカルファイルからのデータロード こちらの機能もライブラリの標準機能でカバーできました。これも自前で実装するとなると地味に面倒な機能だったので良かったです。対応しているファイルフォーマットも複数種類あります。それほど柔軟性はなさそうなので、より細かい要件に対応する場合は自前でファイルのインポート処理を実装して、本ライブラリに組み込むことも可能です。 このような拡張性は後述する他機能においても充実しており、実装例も公式ドキュメントに一通り示されており開発も大きく躓くことなく進められたことも大きかったです。要件の項目で述べた通り、Web 上のナレッジもそれなりにはありました。 Tabulator - Loading Data Tabulator can load data from a wide range of sources, learn how to load data from arrays, JSON and AJAX sources tabulator.info   データバリデーションチェック 実装コストの観点で最も助かったのがこの機能です。 Tabulator - Data Validation Validate user entered data before accepting it into the table tabulator.info 過去のエントリでも言及している通り本アプリケーションの主要機能（要件）でもあり実装は必須でしたが、テーブル定義や制約に準ずるバリデーションチェック機能を全て一から実装するのはさぞかししんどいだろうなと思っていたところ、データ型や標準的な PK/UK（単一列）、NOT NULL など制約のバリデーションチェックは標準機能で対応できたというのがまず助かりました。 複数列による PK/UK 制約（複合キー制約）や FK 制約については未対応だったのですが、ユーザで定義/実装した独自のバリデータを本ライブラリのバリデーション機能に組み込むことができるため、それを活用することでライブラリ側のバリデーションチェックの枠組みの中でこれらのチェックについても実施することができました。フロントエンド（画面）側の機能実装としては山場となったポイントの1つでしたが、これらの特徴のおかげで想定以上にコストを抑えられたのもありがたかったです。 また、バリデーションチェックのタイミングも幾つかの選択肢の中から任意に設定できる点も良かったです。デフォルトでは画面上でデータを編集した直後のタイミングなのですが、先述したローカルファイルからのロードについてはライブラリ上「編集」という扱いではないこと、一時的に列定義/制約に反するデータを入力したいケースもあることが想定されたことの2点より、任意のタイミングでバリデーションチェックを実行できる方が望ましかったのですが、そのような実装も可能だったため支障ありませんでした。 もちろん、バリデーションチェックを実行して合格しない限りはテーブルデータの更新ができない（更新フローが進まない）ようなロジックとしています。   データのプルダウン入力 主に FK 制約のある列の値入力に使用しました。 FK 制約により、入力可能な値は FK 参照先のテーブル/列の値に限定されるため、データを自由入力させずにそれらの値をプルダウン形式で入力できた方がユーザビリティの観点から優れていると考えて、この機能を使用しました。 Tabulator - Editing Data Use built in cell editors to allow users to edit table data, or build out your own for fully customizable table input tabulator.info プルダウン入力候補のデータを動的に定義できることは当然として、候補データのインクリメンタルサーチなども標準でサポートされていたためプルダウン候補の多いデータ入力にも支障ありませんでした。FK 参照先のテーブルからも同時に値を取得する必要があるなど、こちらの機能もフロントエンド（画面）側で山場となったポイントの1つでしたが、同様に実装コストを抑えることができました。   Mutators & Accessors テーブルデータをライブラリを使用して画面表示する際にデータを加工・変換するため機能です。それぞれ、Mutators はデータ自体を変換、Accessors は表示のみを変換します。 Tabulator - Mutators & Accessors Manipulate data as it enters or leaves a table tabulator.info 本アプリケーションにおいては、テーブルデータ内の一部の ID 値を論理名のような分かりやすい表示に変換するために使用しています。具体的には以下のような用途です。 FK 制約のある列に入る値（FK 参照先テーブルの ID 列の値）を、アプリケーションマスタで定義した論理名に変換 論理名自体も FK 参照先テーブルの値を使用しています。例えば、国マスタの ID を国名（論理名）に変換するような処理が可能です。 更新対象行の作成者/更新者列に入る値（ユーザ ID）を、ユーザの氏名表示に変換 ユースケースに応じて Mutators/Accessors を使い分けられる点も含めて機能自体が便利なことはもちろん、データの加工・変換ロジックは自由に実装できるようなライブラリの作りとなっていたため、FK 制約のようにやや複雑な変換ロジックにも対応できました。また、変換ロジックに該当しないようなデータはそのまま変換せず表示することも可能であるため、柔軟性も持たせることができています。   まとめ 正直、このライブラリなしでの本アプリケーションの実装はなかなか厳しかったのでは、と感じるレベルではお世話になりました。テーブル/表の編集機能が必要となるようなアプリケーションの実装では今後積極的に使用していこうと思えるレベルで作りが良かったです。 最も、躓いた点もいくつかあったことはあったので、機会があれば別エントリでまとめてみたいと思います。 本記事がどなたかの役に立てば幸いです。

こんにちは、ＳＣＳＫ　池田です。 LifeKeeperの購入前に、「LifeKeeper」がどういう製品か知りたいことってありますよね？ ネットで検索したり、メーカー公式ホームページを観たり、TechHarmonyを観たり、様々な確認方法があるかと思いますが、製品仕様の細かなところなどはどうしても記載されていないケースがあると思います。 購入前なのに質問できます！ そんな時はなんと購入前でも、メーカーであるサイオステクノロジー社のサポートに質問することができるんです！ サポートへのお問い合わせ方法 – SIOS LifeKeeper/DataKeeper User Portal まず、会社名、部署名、氏名、メールアドレス、連絡先電話番号を入力してください。 その後に「お問い合わせ内容のカテゴリ」を選択します。 選択肢は以下の通りです。 ■お問い合わせ内容のカテゴリ ・価格/構成 ・機能/動作 ・構築環境 ・実績/事例 ・その他 「お問い合わせ内容」を記載して、個人情報の提供にチェックを入れて、最後に「私はロボットではありません」の手続きを踏んでください。 たったこれだけで、サイオステクノジー社からお問い合わせに対する回答を得られます。 また何らかのミドルウェアの構築をご検討でしたら、LifeKeeperのSI&サポートパートナー(ゴールド)のSCSKまでメールにてお問合せください。 SCSK株式会社　LifeKeeperチーム メールアドレス： LK@scsk.jp 公式ホームページ： 「LifeKeeper」で安定稼働を実現 ｜ SCSK株式会社 お問い合わせ・ご相談： HAクラスターソフトウェア「LifeKeeper」 お問い合わせ｜ SCSK株式会社 20年以上に渡る豊富な設計、構築、サポート実績から、お客様の求める可用性の実現のお手伝いをさせていただきます。 それぞれの使い分けとしては、製品仕様など最新情報の入手時にはサイオステクノロジー社のWebフォームから、 SIをご希望、構築可能な構成、LifeKeeperに留まらない様々なパターンの可用性提案をご希望されるような時にはＳＣＳＫへ問い合わせするなどしていただければと思います。 もしＳＣＳＫ　LifeKeeperチームでお答えできない場合でも、ＳＣＳＫ社内の有識者やサイオステクノロジー社と連携しながら、お客様の疑問にお答えさせていただきます！ まとめ 今回は、購入前の問い合わせ方法についてご紹介しました。 問い合わせ方法は大きく３つあります。 ・サイオステクノロジー社の公式サイトのWebフォームから問い合わせる ・ＳＣＳＫのメールアドレスに問い合わせる ・ＳＣＳＫの公式サイトのお問い合わせ・ご相談Webフォームから問い合わせ

Amazon EC2 の外からOSコマンドを実行させるには、AWS Systems Manager (SSM) の SendCommand を用いるのが常道だと思いますが、環境上の制約で使用できない場合もあるかと思います。そこでSSMを使用することなく、OSコマンドを実行させるシンプルな仕組みを作ってみます。 (sshでのコマンド実行は自明ですし、AWSに関係ないのでここでは触れません。)   Systems Manager(SSM)とSendCommandについて 先ずはSSMとSendCommandについて軽く触れます。 SSMの SendCommand とは、SSMのマネージドノードとなっているEC2に対して、EC2の外からOSコマンドを送って実行できます。 「外から送って」と書くと、EC2に外からコマンドが入ってくる形のように思えますが、実際にはEC2で稼働しているssm-agent がSSMのエンドポイントに対してポーリングしており、 コマンドを取ってくる 形になっていると思われます。 (そうでなければEC2へのインバウンド通信許可を必要とするはずですが、実際にはそんなことはしません。) この構成を真似することにします。  構成の概要 上図の構成とします。SSMの位置にSQSを配置し、そこにOSコマンドを入れる。EC2はQueueを定期的に監視するシェルスクリプトを常駐させて、キューにコマンドが入っていればそれをフェッチして実行します。要するにssm-agentの簡易版で置き換えた形だというだけです。(がっかりした人はすみませんm(_ _)m ) 以下、EC2とSQSの内容について簡単に述べておきます。 SQSについて キューは以下の構成とします。 標準キューであるということと、メッセージ保持を1分にしています。あまり長くするとagent役のshellの障害時などにキューにコマンドがたまり、思わぬ昔のコマンドが実行されてしまうことを防いでいます。1分以上フェッチされなければそのコマンドは実行されませんが、そこは割り切っています。また、キューポリシーは適当に設定します。 EC2について シェルが動けば何でもいいですが、上記SQSキューに対して、 sqs:ReceiveMessage および sqs:DeleteMessage の権限が必要ですので、EC2にアタッチするIAMロールに付与しておきます。   ポーリングスクリプトとサービス化 ポーリングスクリプト ポーリングシェルは以下のように作成してみました。シェルの詳細についてはこの話題の主題ではありませんので細かくは触れません。 #!/bin/bash # SQSキューURL (適宜変更) QUEUE_URL="https://sqs.ap-northeast-1.amazonaws.com/xxxxyyyyzzzz/TestQueue" # ログディレクトリとファイル設定 LOG_DIR="/var/log/command-execution" LOG_FILE="$LOG_DIR/command_execution.log" # ログディレクトリの作成 if [ ! -d "$LOG_DIR" ]; then sudo mkdir -p "$LOG_DIR" sudo chown ec2-user:ec2-user "$LOG_DIR" sudo chmod 755 "$LOG_DIR" fi # ログファイル作成 touch "$LOG_FILE" chmod 644 "$LOG_FILE" echo "[$(date)] SQS polling service started." >> "$LOG_FILE" while true; do # SQSからメッセージ取得 RESPONSE=$(aws sqs receive-message \ --queue-url "$QUEUE_URL" \ --max-number-of-messages 10 \ --wait-time-seconds 10 \ --output json 2>/dev/null ) # RESPONSEが空ならデフォルト値を設定 if [ -z "$RESPONSE" ]; then MESSAGE_COUNT=0 else MESSAGE_COUNT=$(echo "$RESPONSE" | jq '.Messages | length' 2>/dev/null) if [ -z "$MESSAGE_COUNT" ]; then MESSAGE_COUNT=0 fi fi if [ "$MESSAGE_COUNT" -gt 0 ]; then echo "$RESPONSE" | jq -c '.Messages[]' | while IFS= read -r MESSAGE; do # ReceiptHandleとBodyを安全に取得 RECEIPT_HANDLE=$(echo "$MESSAGE" | jq -r '.ReceiptHandle' 2>/dev/null) COMMAND=$(echo "$MESSAGE" | jq -r '.Body | @sh' 2>/dev/null | sed "s/^'//;s/'$//") # 無効メッセージ判定 if [ -z "$RECEIPT_HANDLE" ] || [ -z "$COMMAND" ]; then echo "[$(date)] Warning: Invalid message detected. Skipping..." | tee -a "$LOG_FILE" continue fi # コマンド実行 TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S") echo "[$TIMESTAMP] Executing command: $COMMAND" | tee -a "$LOG_FILE" { echo "----- START: $COMMAND -----" eval "$COMMAND" EXIT_CODE=$? echo "Exit Code: $EXIT_CODE" echo "----- END: $COMMAND -----" } >> "$LOG_FILE" 2>&1 # メッセージ削除 DELETE_RESPONSE=$(aws sqs delete-message --queue-url "$QUEUE_URL" --receipt-handle "$RECEIPT_HANDLE" 2>&1) if [ $? -eq 0 ]; then echo "[$(date)] Command executed and message deleted." | tee -a "$LOG_FILE" else echo "[$(date)] Error deleting message: $DELETE_RESPONSE" | tee -a "$LOG_FILE" fi done fi sleep 5 done 5秒(sleep 5)ごとに指定のキューからメッセージの取得を試みます。この値はSQSの料金に影響します。 コマンド実行後はメッセージを削除しています。 また、受け取ったコマンドと実行結果をログに出力するようにしています。オプションでこのログをCloudWatch Logs に連携してもいいでしょう。配置場所は/usr/local/bin/sqs-polling.sh とします。パーミッションは適当につけておきます。 サービス化 上記スクリプトをサービス化するため、systemdのユニットファイルを作成します。 [Unit] Description=SQS Polling Service After=network.target [Service] ExecStart=/usr/local/bin/sqs-polling.sh Restart=no User=ec2-user Environment="PATH=/usr/bin:/usr/local/bin" [Install] WantedBy=multi-user.target 上記を/etc/systemd/system/sqs-polling.service として保存して、以下コマンドでサービス起動・確認します。active(running)を確認してください。 sudo systemctl daemon-reload sudo systemctl start sqs-polling.service sudo systemctl status sqs-polling.service 動作確認 ではキューにコマンドを置いてみます。簡単にSQSのマネコンから実行します。loggerコマンドで/var/log/messagesに文字列を吐き出してみます。   /var/log/messages Feb 28 14:25:59 ip-10-0-0-210 sqs-polling.sh[5414]: [2025-02-28 14:25:59] Executing command: logger "hello . Tech Harmony!!!!!!!!!!!!!!!!!!!!!!!!!!" Feb 28 14:25:59 ip-10-0-0-210 ec2-user[5415]: hello . Tech Harmony!!!!!!!!!!!!!!!!!!!!!!!!!! Feb 28 14:26:01 ip-10-0-0-210 sqs-polling.sh[5422]: [Fri Feb 28 02:26:01 PM JST 2025] Command executed and message deleted. シェルのログファイル [2025-02-28 14:25:59] Executing command: logger "hello . Tech Harmony!!!!!!!!!!!!!!!!!!!!!!!!!!" ----- START: logger "hello . Tech Harmony!!!!!!!!!!!!!!!!!!!!!!!!!!" ----- Exit Code: 0 ----- END: logger "hello . Tech Harmony!!!!!!!!!!!!!!!!!!!!!!!!!!" ----- [Fri Feb 28 02:26:01 PM JST 2025] Command executed and message deleted. となって動作が確認できました。 キューにコマンドを置くことができれば何でもいいので、例えばLambda関数が該当キューにOSコマンドをputすれば、Lambdaが間接的にEC2のOSコマンドを打ったことになります。 最後に EC2から他のAWSサービスへの連携はAWS CLIなどを使えば容易なのですが、AWSサービスからEC2(の中)への連携は手段が限られているように感じましたので、少し考えて作成してみました。 要点は、EC2から外部の状態を取りに行く、という点です。ここではSQSを例にしましたが、S3などを考えても面白いでしょう。 (定期的にS3のあるオブジェクトの存在を確認し、存在すればダウンロードして(以下略)) やったことはssm-agentの超簡易版を作成したに過ぎませんが、そこまで複雑でないことはわかっていただけたと思います。 コマンドの結果をサービス側で知るにはもうちょっと考える必要はありそうです。 SSMが使えるならそちらを使うべきだとは思いますが、色々な制限でそれが叶わない場合の選択肢として、皆様の参考になれば幸いです。 コードの使用は自己責任でお願いいたします。

本記事は 新人ブログマラソン2024 の記事です 。 こんにちは。入社一年目の曲渕です。 現在はAWSの技術習得に向けて勉強している最中です。その際に AWS Cloud9 を使ったAWSのハンズオンを実施したのですが、私のAWSアカウントではCloud9が使用できなくなっていました。そこで本記事では、私と同じような状況になっている方や今年入社される方の参考になればと思い、Cloud9に代わるサービスをご紹介させていただこうと思います。 背景 AWS Cloud9 とは AWSが提供するサービスの一つで、 ブラウザを通じてクラウドベースでコードの記述、実行、デバッグができる統合開発環境(IDE) です。利点として、リアルタイムで共同作業ができることや必要なツールなどがあらかじめ設定されており、開発環境のセットアップが簡単なことが挙げられます。 そんなCloud9ですが、私のAWSアカウントでサービスにアクセスしようとすると、以下のような表示が出ます。   原因は AWSが2024年7月25日以降のCloud9を含むいくつかのサービスで新規利用受付を終了 したためです。そのため、新人の方で私のように配属された後にAWSアカウントを作成した場合は、Cloud9が使用できなくなっています。もしかすると案件などでお客様側からAWSアカウントを払い出してもらった方も同じ状況かもしれません。 （2024年7月25日以前にAWSアカウントでCloud9を使用されていた方は現在でも利用可能です） この問題を解決するために、この記事ではCloud9の代替策となる3つのサービスの概要について記述します。   Cloud9の代替えサービス ご紹介させていただくサービスは以下の3つです。   Amazon SageMaker Studio コードエディタ 概要 Amazon SageMaker Studio コードエディタはAmazon SageMakerの機能の一部です。任意のVPC内に置くことができたりなど、ほぼCloud9と同等の環境を構築することができるというメリットがあります。デメリットとしては起動・削除に時間がかかることやリソースを消したい場合にドメインやユーザーの削除も必要な点が少し面倒です。また、デフォルトでdocker コマンドが使えないため、コンテナを使うためにDockerfileのイメージをリポジトリにプッシュしたいときなどはdockerコマンドのインストールが別途必要になります。   AWS CloudShell 概要 AWS CloudShell は Amazon Linux 2023 ベースのブラウザから操作できるシェル環境です。無料で使用することができ、すぐに実行できるというメリットがあります。ファイルのアップロード、ダウンロードも可能です。しかし、デフォルトのディスク容量が1GBのみのため、大きなファイルを実行するのには不向きというデメリットがあります。また、任意のVPC内に置くこともできません。   Amazon CodeCatalyst 概要 Amazon CodeCatalystは開発者がソフトウェアを迅速に構築、テスト、およびデプロイできるように設計された統合ソフトウェア開発サービスです。CI/CDパイプライン (ソフトウェアの変更を自動でテストし、ビルドし、デプロイするプロセス)を簡単に実現することができ、Cloud9のインスタンスを立ち上げることができるメリットがあります。しかし、現在（2025年2月25日）は東京リージョンで使用することができず、米国（オレゴン）リージョンと欧州（アイルランド）リージョンのみで使用可能となっています。またAWS Builder IDの作成などの初期設定が必要というデメリットがあります。   まとめ 今回はCloud9の代替サービスの概要について簡単にまとめてみました。案件によっては使えないサービスなどもあるかと思いますが、勉強のためのハンズオンの参考になれば幸いです。構築手順については参考資料を見ていただければと思います。また、Cloud9のほかに以下のサービスも新規利用の受付を終了しているようです。 S3 Select CloudSerch SimpleDB Forecast Data Pipeline CodeCommit   参考資料 AWS Cloud9が突然、新規利用不可に？ 代替策「SageMaker Studio コードエディタ」の利用手順 #cloud9 – Qiita AWS CloudShell を早速使ってみました #reinvent – Qiita 【CodeCatalyst 入門①】CodeCatalystの初期設定方法 | わかるブログ Amazon CodeCatalyst 触ってみた! #AWS – Qiita

こんにちは、SCSK株式会社の谷です。 前回、新たに私たちの部署に新入社員として加わった嶋谷さんが、 Mackerel を使ってAWS環境のDocker情報を可視化する方法と結果 についての記事を掲載しました。 ご覧になっていない方は、ぜひ目を通してみてください。 Mackerel で Docker を監視してみた – TechHarmony 今回は、MackerelにてAWSのサーバーレスサービスを監視し可視化しました。 監視対象のシステムについて 今回の検証のため、AWSが提供しているハンズオンから簡易的なWebアプリを構築しました。 名前を入力しボタンを選択すると、「Hello from Lambda」で始まり入力したテキストが続くメッセージが表示されるWebアプリです。 Webアプリの構成は以下の図になります。   構成しているサービスの中で今回は以下を使用して検証をしました。 Amazon DynamoDB 　　 完全マネージド型の NoSQL データベースサービス Amazon API Gateway 　 APIの作成および管理を簡単に行えるフルマネージドサービス AWS Lambda 　　　  　　サーバーレスコンピューティングサービス 上記環境の構築手順について、この記事では説明を省略させていただきます。 詳しく知りたい方は、以下に詳細な構築手順が載っていますので、こちらをご覧ください。 AWS で基本的なウェブアプリケーションを構築する Mackerelでの監視設定手順 ここではMackerelで各サービスを監視するための設定手順について記載しています。 設定手順の詳細につきましては、Mackerel公式ヘルプをご参照ください。 AWSインテグレーション – Mackerel ヘルプ 設定手順について興味のない方は、このパートはスキップして「 Mackerel上で監視データの確認 」のパートに飛んでください。 インテグレーション用のIAMロールの作成 (1) Mackerelの管理画面で「オーガニゼーション名」＞「AWSインテグレーション」をクリックする。 (2)「新しいAWSインテグレーションを登録」というボタンが表示されるため、それをクリックする。 (3) 基本設定＞AWSアカウント　外部IDをコピーする。 (4) AWSのコンソールにログインし、左上の検索バーで「IAM」と入力し、エンターを押す。 (5) 左側のタブからロールを選択し、「ロールを作成」をクリックする。 (6) 以下に沿って入力し、すべて入力後、「次へ」をクリックする。 信頼されたエンティティタイプ ： AWSアカウント AWSアカウント　　　　　　   ： 別のAWSアカウント アカウントID                        ： 217452466226（共通） オプション　　　　　　　　　 ： 外部IDを要求する (7) 今回はLambda、API Gateway、DynamoDBを監視したいため、それらに関するReadOnlyロールを選択し、「次へ」をクリックする。 (8) ロール名と説明を適宜入力し、「ロールを作成」をクリックする。 (9) 作成したロールの詳細画面で表示される、ARNをコピーする。 AWSインテグレーションの作成 (1) Mackerelの管理画面に戻り、先ほど開いた「新しいAWSインテグレーションを登録」画面を開く。   そこで、名前の入力とリージョンの選択を行い、ロールARNの欄に先ほどコピーしたARNを貼り付ける。 (2) メトリックを収集するサービスで、Lambda、API Gateway、DynamoDBを選択する。   他の取得可能なサービスにつきましては以下の公式ヘルプの「 対応しているクラウド製品 」を参照ください。       AWSインテグレーション – Mackerel ヘルプ (3) 「タグを指定して登録するホストを絞り込む」にて連携したいリソースのタグ、除外したいタグを入力する。 (4)「作成」をクリックする。 これで、インテグレーションが作成できました！ 連携確認 以上で設定は完了です。 ここからは、監視設定を入れたサービスの状態を見てみましょう。 ここまでの手順が完了すると、Mackerelの管理画面の「ホスト」のところですぐに確認することができます。 このように、Lambda、API Gateway、DynamoDBの3つのデータが取れていることがわかります。 Mackerel上で監視データの確認 設定作業はいかがでしたか？ 思っていたより簡単に監視ができると感じた方が多いのではないでしょうか。 では、ここからはAWSから連携された監視データがどのように見えているかを、サービスごとに一部抜粋してお見せしたいと思います。 API Gateway MackerelではリソースごとにAPI Gatewayを監視することができます。 API Gatewayでは、基本的に以下のメトリックを取得できます。 詳細はMackerel公式ヘルプをご参照ください。 AWSインテグレーション – API Gateway – Mackerel ヘルプ グラフ名 メトリック 説明 Requests Count 指定期間内のAPIリクエストの合計数 Errors 4XXError クライアント側のエラー数 5XXError サーバー側のエラー数 Cache CacheHitCount APIキャッシュから提供されたリクエストの数 CacheMissCount バックエンドから提供されたリクエストの数 Latency Latency クライアントからリクエストを受け取ってからレスポンスを返すまでの時間 IntegrationLatency バックエンドにリクエストを中継してからレスポンスを受け取るまでの時間 今回は、この中のRequestsのグラフをお見せします。 こちらのグラフは、APIのリクエスト数を可視化したグラフになります。 このデータを見れば、どのタイミングでリクエスト数が増えているかを視覚的に確認することができます。 DynamoDB MackerelではDBリソースごとにをDynamoDBを監視することができます。 DynamoDBでは、基本的に以下のメトリックを取得できます。 詳細はMackerel公式ヘルプをご参照ください。 AWSインテグレーション – DynamoDB – Mackerel ヘルプ グラフ名 メトリック 説明 ReadCapacityUnits ProvisionedReadCapacityUnits プロビジョンドされた読み取りキャパシティユニットの数 ConsumedReadCapacityUnits 読み取り操作で消費されたキャパシティユニットの数 WriteCapacityUnits ProvisionedWriteCapacityUnits プロビジョンドされた書き込みキャパシティユニットの数。 ConsumedWriteCapacityUnits 書き込み操作で消費されたキャパシティユニットの数 Requests ConditionalCheckFailedRequests 条件付き書き込みや更新操作が失敗したリクエストの数 SuccessfulRequestLatency 成功したリクエストのレイテンシー ThrottledRequests スロットルされたリクエストの総数 UserErrors ユーザーによって引き起こされたエラーの数 SystemErrors DynamoDB内部で発生したシステムエラーの数 ThrottleEvents ReadThrottleEvents 読み取り操作がスロットルされた回数 WriteThrottleEvents 書き込み操作がスロットルされた回数 TimeToLiveDeletedItemCount TimeToLiveDeletedItemCount TTL機能によって削除されたアイテムの数 SuccessfulRequestLatency SuccessfulRequestLatency 成功したリクエストのレイテンシー ReturnedItemCount ReturnedItemCount クエリやスキャン操作で返されたアイテムの数 RequestCount ReturnedItemCount クエリやスキャン操作で返されたアイテムの数 TransactionConflict TransactionConflict トランザクションの競合が発生した回数 今回は、この中のWriteCapacityUnitsグラフをお見せします。 こちらのグラフは、DynamoDBへの書き込みで消費されたキャパシティユニット数を示したグラフになっています。 このデータを見ることで、キャパシティを超えるような書き込みが行われていないかを視覚的に確認することができます。 Lambda Mackerelでは関数単位ごとにLambdaを監視することができます。 Lambdaでは、基本的に以下のメトリックを取得できます。 詳細はMackerel公式ヘルプをご参照ください。 AWSインテグレーション – Lambda – Mackerel ヘルプ グラフ名 メトリック 説明 Count Invocations 関数が呼び出された回数 Errors 関数の実行中に発生したエラーの数 DeadLetterErrors デッドレターキューへの送信失敗回数 Throttles スロットルされた呼び出しの数 Duration [ms] Duration 関数の実行時間 Iterator Age [ms] IteratorAge ストリームイベントの処理遅延時間   今回はエラーが分かりやすいようにCountグラフをお見せします。 こちらのグラフは、Lambdaの実行回数（invocations）とエラー回数（errors）を示したグラフになっています。 エラーをグラフ上に表示させるため、14:15頃から LambdaからDynamoDBへの書き込み権限ロールを一時的に削除しました 。 このデータを見れば、いつどのタイミングでエラーが発生し始めたのかを視覚的に確認することができます。 今回ご紹介したグラフはそれぞれ1つずつでしたが、かんたんなカスタムをすれば様々なグラフを作成することも可能です。 興味がある方はぜひ調べてみてください。 終わりに 記事の内容は以上になります。いかがでしたでしょうか。 今回初めてMackerelにて監視設定をいれたのですが、UIも直感的で操作しやすくスムーズに設定を入れることができました！ また、公式ドキュメントも豊富でしたので、疑問点や不明点を解決しやすいところも非常にやりやすかったです。 また、Amazon CloudWatchだと少し手間だと感じていましたが、 設定したいメトリクスを簡単に複数まとめて設定できる ところがMackerelの優れている点だと今回設定してみて感じました。 もう少しMackerelを触ってみようと思いますので、また何か気づきがありましたら記事を掲載します。 最後までお付き合いいただき、ありがとうございました。

はじめに 今回は今年の1月にリリースされたアクションプランという機能の説明と使い方を書いていきます。 アクションプランとは アクションプランとは、リスクのあるリソースが一覧化されており、そのリソースに対し最小限のアクションでリスク軽減をできるように調整された効果的な修復手順を提供し、クラウドリソースの保護に役立てることができます。 アクションプランの使い方 ここからはアクションプランの使い方について解説していきます。 アクションプラン担当者の割り振り Prisma Cloud コンソールにログインします。 このとき「System Admin」でログインしていることを確認します。 上のバーから「アクションプラン」を押下します。 以下画像のように遷移します。 各アクションプランには人を割り当てることもできます。 赤線部分の「Unassigned」部分を押下し、担当する人を選択することができます。 担当者を設定した後に「Assigned to me」を押下する自分がどのアクションプランを担当するか確認することができます。 フィルターの「譲受人」の部分でほかの人が担当するアクションプランを確認することもできます。 逆に担当者が割り当てられていないものは「Unassigned Action Plans」から確認することができます。   アクションプランを解決する場合 Prisma Cloud コンソールにログインします。 このとき「System Admin」でログインしていることを確認します。 上のバーから「アクションプラン」を押下します。 以下画像のように遷移します。 対象のアクションプランを押下して展開すると、対象のアクションプランのプライマリアセットと概要、その影響がとがでてきます。 「プライマリアセット」はどのリソースが対象なのか表示されています。 「概要」は影響を受けるリソースの概要の説明が表示されています。 「影響」は攻撃パス、アラート、脆弱性が表示されています。 展開後、「修正方法」を押下すると解決方法の手順が出てくるので手順実行して修正完了です。 ※修正方法に記載がありますが、「大規模な言語モデルやその他の生成AIを活用する場合があり、エラーが含まれる場合があります。」ということなので注意が必要です さいごに アクションプランを使用して簡単にクラウドリソースのリスクを減らせるようになったのでとても良い機能だと思います。 当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 CSPM ｜ Smart One Cloud Security® Powered by Prisma Cloud from Palo Alto Networks ｜ SCSK株式会社 ご興味のある方は是非、お気軽にお問い合わせください。