DevelopersIO RSS feed【非公式】

RSS feed

Public Key

npub16u6jx85wavk5n0kw5r46ma7dunupsp7acmtn3xys7keqvlsfjxpsar5q5c

Profile Code

nprofile1qqsdwdfrr68wkt2fhm82p6ad7lx7f7qcqlwud4ecnzg0tvsx0cyerqchsuy8z

Publishing to

nos.lol

relay.damus.io

Author Public Key

npub16u6jx85wavk5n0kw5r46ma7dunupsp7acmtn3xys7keqvlsfjxpsar5q5c

Show more details

Last Notes

2024-06-28 11:20:06

【クラメソの「オペレーション・エクセレンス」を支えるメソドロジー #cm_odyssey】
オペレーション・エクセレンスを実現するためにアノテーション株式会社はクラスメソッドグループのオペレーション企業として「オペレーション・エクセレンス」を実現するために、様々な「しくみ」を作り、企業活動の根幹として利用しています。最大の課題は「全チームの業務の見える化・効率化」です。各チームが業務ごとに業務整理や改善を進められるのは、チームの望ましい形であり、多くの企業が進めていると思いますが、客観的多面的な評価や課題の整理全体最適視点での改善などを各チームで進めるのは非常に難易度が高いため、まずは全チームの「見える化」が必要と考えられていました。「業務の見える化」のしくみ作りアノテーション社全体での様々なレベルアップを図るため、部署横断チームとして業務PF推進室（PF：プラットフォーム）が新設されました。主な役割は、「売れる業務・サービスへ導く」というミッションの下、部署横断的に「業務やチーム状態の見える化・測れる化・人材育成」を推進することです。外部にも通用する「オペレーション・エクセレンス」とするため、外部認証やデファクトスタンダードなプロセス（ISMS、ITIL、CMMなど）を取り入れ活用して横展開します。業務PF推進室の最初の取り組みとして、同じ物差しを使った「業務の見える化」のしくみ作りから開始しました。しくみ①（業務成熟度チェック表）課題解決に向けた施策として、まずは各チーム業務を業務単位（ユニットと呼びます）に分けることと、2つのしくみづくりを行いました。 1つ目はCMM（Capability Maturity Model）を取り入れた「業務成熟度チェック表」です。「業務成熟度チェック表」は、業務の成熟度をレベル1～レベル4までカテゴリ分けし、各業務に対しての現在のチームの状態を見える化したものです。業務PF推進室では各レベルに対して下記の定義づけを行いました。レベル0：場当たり的な業務状態レベル1～2：個人依存になっていないか・冗長化できているかレベル3：手順書やスコープ（やること／やらないこと）が明文化されているかレベル4：定期的な計測が出来ているか＜業務成熟度チェック表による変化＞業務成熟度チェック表を用いて定期的にチェック・収集・集計・全社公開したことにより、各チームの状態も日々変化していきました。 3ヶ月間でレベル1（個人依存）からレベル3（見える化）までレベルアップしたチームもありました。さらにレベル3で業務フローや作業時間などが明確になったことで、顧客を含めた大きな改善へ繋がったチームもありました。業務成熟度チェック表により、どの業務が冗長化されていないのか、明文化されていないのか、といった業務ごとの課題が明確になり、チームリーダー・メンバー・関係者も共通認識を持つことができるようになりました。しくみ②（サービスカタログ） 2つ目は、アノテーション全チーム共通フォーマットのサービスカタログです。サービスカタログは作業手順書とは異なり、全業務を一覧化し、各業務の難易度や重要度、作業工数などをまとめたもので、作業頻度・時間・業務量などをカタログ化しています。また、メンバー別の業務可否や育成計画も一緒に管理することで、「業務の見える化」だけではなく、メンバーのスキル習得状況・育成状況の見える化も管理しています。しくみ導入後の成果業務成熟度チェック表、サービスカタログの導入により、下記のような効果がありました。基準と状況見える化により、チーム状態を定量的に評価できるようになった多面的な見える化により、業務課題が見つかり、フロー見直し／業務自動化／メンバー育成などなら品質・スピード・効率化などの改善が進んだ業務難易度設定～「高難易度業務」の定義付け～昇給／社員登用ガイドラインへの反映により、より正しく報酬還元できるようになったチーム内でも、業務難易度・重要度について共通認識しやすくなり、育成の計画化・効率化（育成時間・メンバー管理時間の短縮など）に繋がったこれから業務PF推進室は、上記のような「業務の見える化」後、年々取り組みが変化してきました。チームの様々な状態（顧客関係／業務／メンバー／委託調達）の見える化、リーダー育成のための独自ツールALPSの開発と活用促進（Annotation Leadership Principle Scoring system）（※Google re:Workなども参考に開発）また最近ではCOPC（Customer Operations Performance Center）などを参考に、業務測れる化の基準見直しや、継続的に測定可能なしくみ作りなどを進めています。これらのしくみによって、「オペレーション・エクセレンス」を常に実現できるように、アノテーション社全体を進化させていきます。次に、実際にサービスカタログを応用して「業務の見える化」を進めている営業支援チームの事例を紹介します。業務棚卸のアウトプットを活かした業務の可視化と最適化営業支援チームでは業務棚卸から全体業務像を把握し、眠っている課題を発掘、改善へと導いていくことができないかという視点からサービスカタログを活かし、更なる「見える化」を図りました。フロー図を作成し関連部門へ共有することで課題や改善ポイントの認識合わせに活用しています。フロー図の作成作成したサービスカタログを元に営業アシスタントメンバーにヒアリングを実施し、業務の開始～終了までの一連の流れをフロー図へ落とし込み、業務の交通整理を実施しました。実施したメリットフロー図作成のため業務整理をすることによって当事者自身の頭の中がクリアになり、点と点が繋がり文字のみよりも全体像を捉えやすくなりました。また、関係者と現在の状態や課題を共通認識する際に非常に有効と捉えています。業務課題をフロー図と連動させて、しっかりと業務改善へと繋げていくという可能性も広がりました。さいごに視覚的に表現することで、業務内で関与していない領域についての流れも理解することができるという効果がありました。また、普段気づけなかった疑問や課題について見直すきっかけとなり、今後未開拓な分野の業務についても業務棚卸というネーミングにてサービスカタログ、フロー図の作成を進め、それを活用して更なる業務効率化を目指していきたいと考えています。アノテーションについてアノテーション株式会社は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。「らしく働く、らしく生きる」のスローガンを掲げ、様々な背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けてきました。現在当社では一緒に会社を盛り上げていただけるメンバーを募集中です。少しでもご興味あれば、アノテーション株式会社WEBサイトをご覧ください。
https://dev.classmethod.jp/articles/process-innovation/

2024-06-28 11:16:56

【Xcode Preview CanvasでSwiftDataのサンプルデータを表示する】
こんにちは、製造ビジネステクノロジー部の嶋村です。最近、個人のアプリ開発でSwiftDataを使い始めました。開発を進める中で、XcodeのPreview Canvas上でテストデータを使って表示させたいと感じ、調べてみました。今回は、XcodeのPreview Canvas上でどのようにサンプルデータを表示するか、その方法について調べたことを書こうと思います。今回作ったもの今回は簡単なTodoアプリを作りました。 Preview Canvasでサンプルデータを表示するまずは、プレビュー用のサンプルデータを作る前に用意したTodoアプリのモデルです。今回はタイトルと完了状態のシンプルなものにしました。いよいよサンプルデータを作っていきます。ここでは、4つのTodoオブジェクトを作成しました。次にモデルコンテナを作っていきます。ここでは、ModelContainerを作成しています。このModelContainerには、先ほど作成したサンプルデータを挿入していきます。具体的には、try ModelContainer(for: Todo.self, configurations: ModelConfiguration(isStoredInMemoryOnly: true)) でModelContainerを作成し、その mainContext に SampleData.todos.forEach { modelContext.insert($0) } でサンプルデータを挿入しています。これにより、プレビュー用のデータがModelContainerに格納されます。最後に、サンプルデータを挿入したModelContainerを返却しています。最後に#Previewの設定部分で、先ほど作ったpreviewContainerを読ませてあげることで、サンプルデータがPreview Canvas上で確認できるようになります。さいごに今回は、Preview Canvasでテストデータを入れて確認できるようにしてみました。この方法はApple Developerの公式動画上で写ったものを参考に作成しました。普通に調べるとなかなか出てこないので、ブログで書いてみました。私と同じようになかなか探し出せない人の助けになればと思います。最後までお読みいただきありがとうございました！ではまた、嶋村星哉でした〜。
https://dev.classmethod.jp/articles/xcode-preview-canvas-swift-data-sample/

2024-06-28 11:13:46

【Alteryx Analytics CloudからGoogle BigQueryへのConnectionの設定 #Alteryx】
こんにちは、スズです。本記事では、Alteryx Analytics CloudからGoogle BigQueryへの接続とデータのインポートについてご紹介します。Alteryx Analytics Cloudにデータをインポートすることで、Alteryx Designer Cloudなどでデータを使用することができるようになります。前提 Alteryx Analytics CloudからGoogle BigQueryに接続する際、認証タイプとしてService Account KeyまたはOAuth 2.0を選択できますが、今回はService Account Keyを使用します。 Google BigQueryでは、Alteryx Analytics Cloudに接続する専用のサービスアカウントを作成しています。サービスアカウントに必要な権限については、Alteryxのドキュメントをご確認ください。作成したサービスアカウントからJSONキーのファイルを生成しておきます。 Alteryx Analytics CloudからGoogle BigQueryへの接続 Connectionの作成 Alteryx Analytics Cloudの[Connections]を開き、[Create Connection]をクリックします。 [Google BigQuery]を選択します。 Connection Nameなどを設定して[Create]をクリックします。設定する項目には以下のものがございます。項目内容 Connection Name Alteryx Analytics Cloudで表示する名前を指定します。 Connection Description 作成するConnectionの説明を入力します。（オプション） Project Id 接続先のGoogle BigQueryのプロジェクトIDを設定します。 Credential Type 認証タイプにService Account KeyまたはOAuth 2.0から選択します。 Service Account Key 認証タイプにService Account Keyを選択した場合、キーを入力します。 OAuth 2.0 client OAuth 2.0 clientを選択して認証します。今回、Google BigQueryへの認証にはService Account Keyを使用しています。Service Account Keyの入力欄には、Google BigQueryで取得したJSONキーのファイルを開き、コピーしたものをAlteryx Analytics Cloudの画面上に貼り付けています。 [Connections]タブに戻り、作成したConnectionが表示されます。ここまででAlteryx Analytics CloudからGoogle BigQueryへの接続が作成できました。データのインポート Google BigQueryのデータをAlteryx Analytics Cloudで使用するには、Connectionを作成した後にデータをインポートする必要があります。[Data]タブから[Import Data]をクリックします。左ペインにて作成したConnectionをクリックすると、Google BigQueryのデータベースが表示されます。インポートしたいデータがあるデータベースを選択します。テーブルの一覧が表示されますので、プラスボタンをクリックします。右ペインにテーブルから取得したデータセットが表示されます。データセットを確認する場合は[Edit Settings]をクリックするとプレビュー画面が表示されます。プレビューで確認した後は[Save]をクリックして戻ることができます。[Continue]をクリックするとデータセットをインポートできます。 [Data]タブに戻り、インポートしたデータが表示されます。これでAlteryx Designer Cloudなどでインポートしたデータを使用できるようになります。最後に Alteryx Analytics CloudからGoogle BigQueryへの接続とデータのインポートについてご紹介しました。参考 Google BigQuery Connections
https://dev.classmethod.jp/articles/alteryx-analytics-cloud-connection-google-bigquery/

2024-06-28 01:13:46

【Workflowsの組み込み環境変数について調べてみた】
組み込み環境変数とは Workflowsには変数名がGOOGLE_CLOUDから始まるいくつかの環境変数が定義されています。(英文のリファレンスでは[Built-in environment variables]と書かれていますね。この組み込み環境変数は特に宣言する必要もなく、宣言を必要とせず、すべてのワークフロー実行で利用可能です。使用できる組み込み環境変数は以下となっています。環境変数名内容 GOOGLE_CLOUD_LOCATION ワークフローが存在するLocation GOOGLE_CLOUD_PROJECT_ID プロジェクトID GOOGLE_CLOUD_PROJECT_NUMBER プロジェクト番号 GOOGLE_CLOUD_SERVICE_ACCOUNT_NAME ワークフロー実行サービスアカウント名 GOOGLE_CLOUD_WORKFLOW_EXECUTION_ID ワークフロー実行ID GOOGLE_CLOUD_WORKFLOW_ID ワークフローのID GOOGLE_CLOUD_WORKFLOW_REVISION_ID ワークフローのリビジョンの識別子使い方・確認方法・メリットなどどうやって使うの？通常の環境変数を取得する時と同様に${sys.get_env("変数名")}で取得することができます。例えばGOOGLE_CLOUD_PROJECT_IDを取得する場合であれば以下の実装になります。環境変数名は文字として渡す必要があるので、ダブルクォーテーションで囲う点に注意してください。これは組み込み環境変数だけでなく通常の環境変数も同様です。 To access an environment variable, make a call to the sys.get_env() function in an expression, passing the name of the environment variable as a parameter. The name of the environment variable must be passed as a string. 環境変数にアクセスするには、式の中でsys.get_env()関数を呼び出し、パラメータとして環境変数名を渡す。環境変数名は文字列として渡さなければならない。(DeepL翻訳) ※引用：https://cloud.google.com/workflows/docs/reference/environment-variables#access_built-in_environment_variables 組み込み環境変数を確認する以下のワークフローを実行すると、組み込み環境変数がログ出力されます。何がメリットなの？プロジェクトIDや番号で本番・検証環境を出し分ける、障害発生時などに調査が楽なようにサービスアカウント名やワークフロー実行IDなどをログや通知メッセージに載せる、などでしょうか。補助的な用途に使うものと考えます。まとめ組み込み環境変数は大活躍するような存在ではなく、縁の下の力持ちのようなみんなを確かに支えてくれる優しい存在だと考えます。なのでWorkflowsを活用していく上では組み込み環境変数の存在は押さえておくと引き出しが増えていいのかなと思います。この記事がどなたかのお役に立てば幸いです。それではまた。参考 Built-in environment variables
https://dev.classmethod.jp/articles/20240627-workflows-env/

2024-06-26 12:13:46

【アップデートされたNotion外部共有「Notion Sites」を試してみた #Notion】
NotionはページをWeb公開することで所謂ホームページとして扱うことができます。直近のアップデートでいくつかのオプションが加わりました。実際に触ってみた上での内容説明記事となります。新しいWeb共有新しくなったWeb共有はNotionのページをWebサイトとして設定する上で、編集したいオプションを手軽に変更できるようになっています。ページ階層をリンクとして表示切り替えサイト内検索の有効切り替えテンプレートとしての流用許可「Notionで構築」表示切り替えサイトプレビューの設定テーマカラー設定ページアイコンと異なるファビコンの設定 GoogleAnalyticsの設定この中で「Notionで構築」表示はカスタムドメイン設定の追加有料オプションが前提となります。ページ階層をリンクとして表示切り替えサブページを用いていない場合には表示をオフにするとよいでしょう。サイト内検索の有効切り替え Notionの検索機能を利用したサイト内検索が有効になります。旧プラスプランにて確認した限りでは外部検索エンジンのサインが見当たらないため、恐らくNotion独自の検索でややコツが求められるかもしれません。テンプレートとしての流用許可レイアウトをテンプレートとして流用することを許可する場合にはオンにしておきます。「Notionで構築」表示切り替え「Notionで構築」ボタンがページ右上に表示されます。Notionの利用状況にて押した際の遷移先が変わってきます。クリックした人遷移先 Webサイト所有者本人編集画面 Notionログイン済の人自身のアカウント Notion未ログインの人 Notionサインアップサイトプレビューの設定 SNSでURLを共有した際にカード型プレビューとして表示される内容を指定します。見せたいカットを手軽に設定できるので便利です。テーマカラー設定ライトカラーあるいはダークカラーの設定を行います。いずれかのカラーに固定したくない場合はシステムを選択しましょう。ページアイコンと異なるファビコンの設定初期はページのアイコンが自動設定されていますが、この設定を変えることでブラウザのタブに表示されるアイコンとページ内のアイコンをそれぞれ別にすることが可能です。 GoogleAnalyticsの設定 Notion上で可能な操作は測定用IDの入力のみです。Analytics自体はGoogle Analyticsで別途設定が必要です。カスタムドメイン設定の有料オプション「Notionで構築」表示をオフにしたい場合には必須となります。1年辺りUS$96です。6月26日 7:39 UTC時点では15349円となります。利用しない場合はnotion.siteドメインが設定されます。notion.siteドメイン数制限は以下の通りとなります。プラン notion.siteドメイン数フリープラン 1 旧プラスプラン 1 プラスプラン 5 ビジネス 5 エンタープライズ 5 自ずとフリープラン、旧プラスプランは1つのホームページ下に用途別サブページを持つ構成となるでしょう。あとがき公開直後は外部検索エンジンの対象から外れており、検索対象にする場合にはオプションをオンにする必要があります。プロフィールページや個人ホームページとしての利用と見る場合、カスタムドメインを使わずとも十二分な機能はあるといえます。難点はページ内にアップロードした画像やファイルの管理でしょうか。同期ブロックの活用など工夫が要るかもしれません。独自のCGIやスクリプト埋め込みを行いたい場合には向きませんが、文章や画像等の静的リソース外部共有を素早く行いたいときにはおすすめの選択肢です。
https://dev.classmethod.jp/articles/2024-06-26-tried-the-updated-notion-external-sharing-notion-sites/

2024-06-26 11:23:13

【[セッションレポート] 労働力不足の現場を救う！「京セラロボティックサービス」を支えるクラウド基盤の開発ストーリー #AWSSummit】
セッション概要労働力不足の現場を救う！「京セラロボティックサービス」を支えるクラウド基盤の開発ストーリー京セラ株式会社では協働ロボットを AI で知能化するクラウドサービス「京セラロボティックサービス」を開発し、昨 2023 年 11 ⽉にローンチしました。本サービスではロボットをクラウドに接続することで、段取り替え作業の短縮や作業品質の維持／改善、リモートサポートなどを実現しています。また、ロボットへの接続、及び、お客様の現場環境データをお預かりすることから、AWS Organizations などのサービスを⽤いて複数アカウントの統合管理を⾏い、セキュリティとプライバシーを重視して環境構築に努めています。このセッションでは、ローンチまでの 4 年間に渡るプロジェクトの概要とサービスを⽀える技術を紹介します。スピーカー京セラ株式会社ロボティクス事業部サービス技術開発センターアプリケーション開発チーム責任者巽健人氏クラスメソッド株式会社代表取締役横田聡 ※ 横田のパートのセッションレポートは割愛します。先にまとめ(レポーターの感想) 本セッションでは、京セラ株式会社が開発した「京セラロボティックサービス」の裏側にある技術と開発プロセスが詳しく紹介されています。「協働ロボットの知能化」という革新的なサービスの実用化に向けた取り組みは、多くの企業にとって参考になるはずです。AIやクラウドといった最先端の技術を扱ったサービスですが、実用化のためにはやはり高レベルでのセキュリティやプライバシー保護の実現は必要不可欠であり、この部分での徹底したこだわりはどの企業も見倣うべき点であると感じました。特にAWS Organizationsを活用したシングルテナント構成についてはぜひチェックいただきたいです。また、弊社クラスメソッドとの協業姿勢も素晴らしいと思います。私自身、このプロジェクトに長年携わる中で、単なる発注者・受注者の関係を超えた、互いの専門性を尊重し合うパートナーシップを実感してきました。京セラ社は我々のスキルを信頼し、高い裁量を与えてくださいます。そのため、未経験分野への挑戦など、チャレンジングながらもやりがいのあるタスクに取り組む機会が多くあります。本セッションで紹介された「WIN-WIN の関係性を築く」という協業方針は、このような良好な関係性の根拠となっています。これは、様々な立場の方々との協業において、関係性構築のヒントになるのではないでしょうか。セッションレポート会社紹介京セラ株式会社は、1959年に創立、セラミックの焼成から始まり、電子部品やソリューションなど多岐にわたる事業を展開する多角経営企業として成長してきました。創業時のベンチャー精神を大切にし、常に新しい分野への挑戦を続けています。その精神は今日も脈々と受け継がれており、新規事業への積極的な取り組みが行われています。その一例が、本題材で取り上げる京セラロボティックサービスです。「京セラロボティックサービス」紹介ロボットを知能化することで活用シーンを増やす京セラロボティックサービスは、協働ロボットを活用した革新的なソリューションを提供しています。協働ロボットとは、人間と同じ作業空間で安全に協力して働くことができる産業用ロボットのことで、近年、様々な産業分野での導入実績が急速に増加しています。しかし、多品種少量生産の現場では、協働ロボットの導入にいくつかの課題がありました。具体的には、部品登録や変更に伴う手間とコストの増大、そして不規則な工程や不定形部品への対応の難しさが挙げられます。これらの課題に対し、京セラはAIと3Dビジョンによる「ロボットの知能化」というアプローチで解決策を提示しています。このシステムでは、京セラの貸与しているAIコントローラー（エッジコンピュータ）を介してロボットがクラウドに接続しており、サブスク形式で簡単にご利用いただけます。お客様は専用のクライアントアプリケーションを通じて、ロボットに簡単に作業をオーダーすることができます。さらに、ロボットの状態や稼働状況をリアルタイムで確認することが可能となり、生産管理の効率化にも貢献します。加えて、京セラのエンジニアによる専門的なサポートも提供されており、導入から運用まで一貫したサービスを受けることができます。このように、京セラロボティックサービスは、最新のテクノロジーと専門知識を組み合わせ、製造業の課題に対する包括的なソリューションを提供しています。クラウドやAIを活用することによって、最低限の手間やコストでお客様の現場に協働ロボットを導入することが可能です。ロボティクスを “クラウドサービス” として提供するために本新規事業は 2019年に着手開始し、2023年11月にローンチとなりました。ローンチに至るまでの4年間にわたるプロジェクトの概要と、サービスを⽀える技術を紹介します。事業を取り巻く環境事業立ち上げにあたり、どのように開発を運用していくか？という点が課題に挙がりました。前述の通り、協働ロボットの導入事例は増加傾向にあるものの、ロボットを知能化するソリューションはプロジェクト開始当初はまだ他社も展開しておりませんでした。我々が先駆者として道を切り開く必要がありました。さらに、クラウドやAIなどといった、急速に進化する技術を常にキャッチアップし、プロジェクトに反映させていくことも求められます。このような不確定要素が多くかつ変化の激しい環境下では、内製化とアジャイル開発の採用が不可欠だと判断しました。アジャイル開発では、各イテレーションで提供できる価値が開発チームの実力に直結し、それがサービスの品質を左右します。そのため、まずは強固な内製化体制の構築に注力しました。一方で、社内リソースのみに依存すると既知の技術や知見に固執する「技術のサイロ化」のリスクがあります。これを避けるため、外部の知見も積極的に取り入れ最適化を続けていきたいとも考えていました。また、本ロボティクスサービスには様々な重要な要件が存在します。たとえば、セキュリティは安全性に直結するため最重要事項です。なぜなら、このサービスではロボットのハードウェアがクラウドに接続されており、万一セキュリティの脆弱性がロボットの誤動作を引き起こすと重大な事故につながる可能性があるからです。さらに、情報漏洩は絶対に防がなければなりません。本サービスは顧客の工場内の機密情報を扱うため、仮に漏洩が発生してしまうと、顧客のビジネスに甚大な損害を与えるだけでなく、当社の信頼性も著しく損なわれる可能性があります。このような要件から、AWS Organizations を活用し1 顧客につき 1 AWS アカウントのシングルテナント構成を採用することとしました。AWSにおいては、アカウントの境界がデフォルトのアクセス許可の境界となるためです。また、テナントアカウントではマネージドサービスを積極的に活用することで、運用負荷軽減、コスト最適化を図っています。加えて、各テナントアカウントに同構成のリソースを展開する、ログの集約化、セキュリティの設定など、サービスを運用するにあたり様々な業務が必要になります。これらを可能な限り自動化、省力化していくことも必要だと考えました。これらの要件を満たすためにはAWSの高度なナレッジが必要になります。専門性の高い開発パートナーを探していたところ、AWSから紹介いただき、クラスメソッド社との協業が実現しました。クラスメソッド社との協力体制クラスメソッド社との協業にあたり、以下 3つの方針を策定しました。 1. 一緒にチームとして開発する前述の通り内製化が前提のプロジェクトのため、クラスメソッド社員が作成したコードも必ず京セラ社員がレビューを行ない、承認後にマージするプロセスとしています。時には我々が書いたコードをクラスメソッドの方にレビューいただくといった逆のパターンを採ることもあります。 2. 効率的なコミュニケーション体制基本的にはSlackやチケットを介した非同期コミュニケーション中心に行ない、同期的なコミュニケーションは週一回のオンライン定例ミーティングのみとしています。これにより、集中して作業に取り組むことができる環境が実現されています。プロジェクトが開始したのがコロナ禍真っ只中だったことと、クラスメソッド社の社員が全国各地から参加していることもあってこのような方法を採っています。 3. WIN-WIN の関係性を築くプロジェクトの都合上どうしても難しい場合もありますが、できる限り各メンバーの関心のある技術領域に関するチケットを担当いただき、成長につなげていただきたいと思っています。ブログの会社でもあるクラスメソッドなので、「ブログに書ける」タスクの依頼を意識するようにしています。これは、我々がクラスメソッドに求めているのは単なる開発ではなく、本ロボティクスサービスに新たな技術や知見を取り込みたいと考えているためでもあります。構築例1: ユーザー管理者向け Web サービス構築例2: SecOps 構築例3: CI/CD パイプラインビジネスのスケールに向け京セラロボティックサービスは2023年11月にローンチし、現在社内外にて導入やマーケティングを進めています。グローバルで数千台規模へのスケールを目指して日々開発を行なっております。ローンチに伴い、開発のフェーズも変わります。サービス開発に適用できる工数が減る一方、実運用に伴い、優先度の高い要件が増えていきます。クラスメソッドと構築してきた統合運用や DevOps の仕組みを活かし、ユーザーニーズに沿った対応を進めていきます。今後も京セラロボティクス事業部のミッションである「共に働き、共に考え、共に成長する人と機械が共存する未来の現場を創る」の実現に向け、クラスメソッド社とともにより良いサービスの提供を目指してまいります。スライド現在 AWS Summit Japan 2024のポータルで登録を行なうと、本セッションのスライド資料をダウンロード可能です。以下より登録を行なってください。 AWS Summit Japan | 2024 年 6 月 […]
https://dev.classmethod.jp/articles/aws-summit-japan-2024-kyocera-robotic-services/

2024-06-26 11:13:46

【Knowledge bases for Amazon Bedrockのプロンプトテンプレートとチャンク数を調整し、電話での問い合わせから種別判定の精度とレスポンス速度を改善する】
はじめに以前の記事では、Amazon Connect、Knowledge bases for Amazon Bedrock、およびAmazon Lexを組み合わせて、電話での問い合わせ内容を種別判定し、最適な担当者に振り分ける方法とその精度結果について解説しました。構成は以下の通りです。 Amazon Connectのフロー内の構成は以下の通りです。以下は、ユーザーのお問い合わせ内容を種別判定し、その内容に応じて適切な担当者に振り分けるまでのフローです。電話でユーザーがお問い合わせ内容を伝えます。ユーザーからお問い合わせ内容をLexで受け取ります。インテントは、FallbackIntentを呼びます。受け取った内容をKnowledge bases for Amazon Bedrockで種別判定します。事前にお問い合わせの種別内容をデータソースであるS3バケットにアップロードしておきます。 Knowledge basesでは、生成された回答に対して参照したドキュメント情報もレスポンスされますので、ドキュメント情報内のファイル名を特定して種別判定します。お問い合わせの種別によって、適切な担当者に振り分けを行います。以下は、Knowledge bases for Amazon Bedrock（RAG）のイメージ図です。引用 LambdaからKnowledge basesで種別判定を行う際、以下の問題点がありました。種別判定の精度検証結果では質問文に対して正しく種別判定されたのは、25問中21問であり、４問ミスがあった。（検証結果内容は後述します）入力トークン数検証時、Knowledge basesにおける回答モデルの入力トークン数が2400程度と多い。コストや処理時間に影響するレスポンス速度 LambdaからKnowledge basesにリクエストし、実行完了までに6~8秒かかる。電話における6~8秒は長いと感じてしまう本記事では、上記の問題点を改善するため、Knowledge basesにおいて以下の2つの対策を実施します。チャンク数を減らすチャンクとは、ドキュメントを効率的に検索・処理するために分割された、意味のある小さなテキスト単位です前回記事では、Knowledge basesのチャンキング戦略は、チャンク化なし（各ファイルを 1 つのチャンクとして扱う）にしています。チャンク数を減らすことで、入力トークン数は削減し、レスポンス速度は向上する見込みです。ただし、種別判定の精度は、下がる可能性があります。デフォルトプロンプトテンプレートをカスタマイズするデフォルトプロンプトテンプレートを利用し、Knowledge basesで回答生成が生成されます。デフォルトのプロンプトテンプレートを修正することで、精度向上やプロンプト数削減により、レスポンス速度の改善が見込まれます。これら2つの改善策は、Knowledge basesにリクエストを送るLambda関数のコードを修正することで実装できます。今回以下の記事を参考にしました。 Lambdaのコード Lambdaの主な設定は以下の通りです。ランタイム：Python 3.12 タイムアウト：15秒メモリ：512MB IAMの管理ポリシーを適用 AmazonBedrockFullAccess チャンク数の設定やKnowledge basesのプロンプトテンプレートを修正する場合、2024/6/26時点ですと、boto3を最新バージョンにする必要があります。ローカルから最新バージョンのboto3をzip化し、Lambda Layerにアップロードします。全体のコードは以下の通りです。LexからLambdaが呼ばれ、Knowledge basesで種別判定後、close関数で、お問い合わせ種別をLexのセッション属性としてConnectフローに返します。詳細は、前回の記事をご参照ください。今回実装したコードは以下の通りです。 knowledgebaseIdは、作成したKnowledge basesのIDを入力下さい。チャンク数の設定 vectorSearchConfigurationのnumberOfResultsでチャンク数を設定できます。チャンク数は、2つにしました。カスタムプロンプトテンプレートの活用 textPromptTemplateでカスタムプロンプトテンプレートを指定しています。 Knowledge basesのプロンプトテンプレートでは、Knowledge basesで事前に定義されたプロンプトプレースホルダーと呼ばれる変数が利用できます。例えば、プロンプト内のプロンプトプレースホルダー$search_results$は、ユーザークエリで取得した結果(ドキュメント検索結果)になります。詳細は、ドキュメントをご参照ください。今回の上記のLambdaのコードで以下の対応ができました。チャンク数を減らす Knowledge basesのデフォルトプロンプトテンプレートをカスタマイズする前回同様に、実際に質問文から種別判定し、判定結果を確認してみます。検証結果種別判定前回の検証結果では、種別判定は、25問中21問が正しく種別判定されていました。前回の検証結果質問文 Kendraでの種別判定 OK/NG カードを紛失してしまい、不安です。どのように対応すべきでしょうか? カードの紛失 OK 残念ながらカードを盗まれてしまいました。早急に何か手続きが必要でしょうか? カードの紛失 OK カードを無くしてしまい、新しいカードが必要になりました。再発行にはどのような手続きと費用がかかりますか? カードの紛失 OK カードの暗証番号を完全に忘れてしまいました。暗証番号を再設定するにはどうすればよいでしょうか? カードの紛失 OK 新しく口座を作りたいのですが、必要な書類を教えてください。口座開設 OK 16歳の子供が口座を持ちたがっています。親の同意は必要でしょうか? […]
https://dev.classmethod.jp/articles/knowledge-bases-for-amazon-bedrock-inquiry-type-improvement/

2024-06-26 10:13:46

【投影ポリシーと集計ポリシーを適用したテーブルを Tableau から参照してみる #SnowflakeDB】
はじめに 2024年5月のリリースで、Snowflake でデータ保護のために使用できるポリシーである投影ポリシーと集計ポリシーが一般提供となりました。こちらの機能について、概要をまとめつつ BI ツール（Tableau）からどのように見えるかを確認したく記事としました。投影ポリシー投影ポリシーをカラムに対して適用すると、ポリシー定義に基づき、そのカラムを選択するクエリを実行可能とするか、つまり指定のカラムをセレクト句に含めることを許可するかを制御できます。以下は公式ドキュメント記載のポリシーの例です。この例の場合は、クエリを実行したユーザーのロールに基づいて、対象のカラムを選択可能かコントロールします。保護したい個人情報などを含むカラムに対してマスキングポリシーを適用したり、そもそも保護したい列を含まないビューを定義した場合との違いとして、この機能により保護されたカラムはセレクト句に含めることはできませんが、例えば結合のキーとして使用することが可能です。これにより、個人情報などを保護しつつレコードレベルで複数のテーブルにまたがる分析が可能となります。投影ポリシーに関する主な特徴として以下があげられます。 SQL クエリの出力に列を投影できるかどうかを定義するスキーマレベルのオブジェクトカラムには一度に1つの投影ポリシーのみを割り当て可能投影ポリシーで保護したカラムに対して、マスキングポリシーを適用したり、対象のカラムを含むテーブルに対して行アクセスポリシーを適用することも可能この場合「行アクセスポリシー」による行フィルター、「投影ポリシー」によるクエリの許可、「マスキングポリシー」による列マスクが順に適用されるタグベースの投影ポリシーは現時点では使用できない（タグに投影ポリシーをセットすることはできない） SYSTEM$GET_TAG_ON_CURRENT_COLUMNによるポリシー定義は可能仮想列または外部テーブルの VALUE 列には適用できない詳細は以下をご参照ください。集計ポリシー集計ポリシーは、テーブルやビューに対して適用されます。この際、ポリシー定義に基づき対象のテーブルに対するクエリとしてグループに集計することを強制します。これにより、個々のレコード単位の情報を返すことが防がれ、行レベルのプライバシーとして機能します。集計ポリシーの主な特徴は以下です。テーブルまたはビューのデータにアクセスできるクエリの種類を制御する、スキーマレベルのオブジェクトウィンドウ関数は、集計制約付きテーブルまたはビューに対するクエリでは使用できないテーブルまたはビューに関連付け可能な集計ポリシーは1つのみ詳細は以下をご参照ください。また、集計ポリシーを定義する際はあわせて以下を考慮します。最小グループサイズエンティティキー最小グループサイズ例えば以下のようなテーブルに対して集計ポリシーを適用したとします。ここで以下のクエリで部署ごとの平均 Salary を算出してみます。集計ポリシーは、テーブルに対する集計を強制するため、上記のようなクエリは実行でき、この場合出力は以下のようになります。最終行の部署 HR を見てみると、このグループ部署に属するレコード数は１なので、実質個人を特定可能な結果を得ることができています。そこで集計ポリシーを定義する際はMIN_GROUP_SIZEとして集計時のグループに含まれる最小のレコード数を指定します。これにより、最小グループサイズよりも少ないレコードを含むグループがある場合、それらのグループに属するレコードを remainder group としてまとめ、結果を返します。この際、グループのキー項目値は NULL とされます（複数のグループからなる可能性があるため）。さらに remainder group に分類してもMIN_GROUP_SIZEに満たない場合は、結果のすべてのフィールド値が NULL として返されます。この例でMIN_GROUP_SIZEを2として設定すると HR グループが remainder group に分類されます。ただし、この場合でもMIN_GROUP_SIZEを満たすレコード数には足りないため、すべてのフィールドが NULL として出力されることになります。エンティティキー集計ポリシーではMIN_GROUP_SIZEとあわせてENTITY KEYを指定できます。これにより集計グループに含まれるレコード数だけでなく、指定のキーについてMIN_GROUP_SIZE以上の種類数含まれるように制限することが可能となります。先のデータに年の情報を追加した以下のような、年ごと部ごとに集計可能なテーブルがあるとします。ここで同じようにMIN_GROUP_SIZEとして2を指定した集計ポリシーを適用したとし、先と同じ集計クエリを実行すると以下の出力となります。 HR 部門については、一名の情報しかありませんが、複数年にまたがるレコードがあるためMIN_GROUP_SIZEの制約を満たし出力が返ってきます。しかし、この例では実質個人の Salary ができてしまっている状況です。そこで集計ポリシーをテーブルに適用する際にENTITY KEYとして [USERNAME] カラムを合わせて指定します。その上で同じクエリを実行すると以下の出力となります。集約のレコード数は指定の条件を満たしていますが、部門でテーブルをグループ化した際に、ENTITY KEY として指定した [USERNAME] がのユニーク数が2未満のため remainder group に分類され、さらに十分なレコード数がないためにすべてのフィールド値が NULL として返されます。環境の用意ここでは以下のコマンドで検証用のデータベース・スキーマ、ロールを定義しました。投影ポリシーの作成サンプルデータとして作成した２つのテーブルには、個人情報として [email] が含まれています。個人を特定可能な [email] を保護しつつ、２つのテーブルを結合し部門単位での Salary の集計を行いたい、というような設定です。ここでは以下のコマンドで投影ポリシーを作成しました。ポリシーの作成にはスキーマ内の CREATE PROJECTION POLICY 権限が必要ですが、上記でポリシー作成用のロールがスキーマの所有者となる構造のため、この権限を明示的に付与していません。ポリシーは、現在のロールが SYSADMIN 以上であれば制約無し、それ以外であればポリシーが適用される設定です。ポリシーをカラムに適用するには、以下のいずれかの権限が必要です。アカウントに対する APPLY PROJECTION […]
https://dev.classmethod.jp/articles/projection-agg-policies-from-bi-tableau/

2024-06-24 13:13:46

【Cloud Run ジョブでCloud Storage FUSE機能を使ってみた】
Cloud Storage FUSE機能とは Cloud Runのコンテナで、Cloud Storageのバケットがストレージボリュームとして扱うことができるようになる機能です。この機能を用いてバケットをマウントすると、バケット内のデータをコンテナ内のファイルとして扱うことができます。例えば以下のようなバケットがあるとします。上記バケットをCloud Storage FUSE機能でマウントしてコンテナを作成すると、コンテナ実行時は以下のような状態になります。注意点 2024/6/24時点ではプレビューとなっていますマウントするバケットへのアクセス権限をCloud Run ジョブのサービスアカウントに付与されていること何点か制限事項がある料金 FUSE自体の料金は発生しませんが、Cloud Storageの料金は発生します。コンテナ内のディレクトリの一つとして扱うことができますが、リファレンスに以下の通りにあるように実態はCloud Storage APIになります。 Cloud Storage FUSE は、FUSE と Cloud Storage API を使用して、ファイルシステムのローカルにマウントされたフォルダのようにバケットを透過的に公開します。 ※引用：https://cloud.google.com/storage/docs/gcs-fuse?hl=ja#technical-overview よって、例えばコンテナ内でファイル操作(解凍、圧縮)などを行うとコンテナにデータがAPIでコピーされてコンテナ内で処理され、またバケットへ戻すというような動きになりそれぞれのCloud StorgaeAPIの料金が発生します。使い方 Cloud Run ジョブをデプロイするとき、または更新することでマウントすることができます。以下は既存のジョブを更新してマウントする、リファレンスのコマンド例です。 --add-volumeと--add-volume-mountを指定して、ボリュームのマウントを行います。ジョブのデプロイ時にマウントをするには同様に左記のフラグを用いることで可能となります。実際に使ってみる事前準備 Cloud Shell上で実際にコンテナを作成して試してみました。作成したファイルとしては以下となります。 Dockerfile script.sh：検証用コード deploy.sh：デプロイコマンドそれぞれのファイルを以下に示します。 Cloud Storageバケットは作成されていることを前提としています。作成したバケット名をcloud-storage,bucket=に指定します。 --add-volume-mountで指定したマウントパスでバケットはマウントされます。今回は事前に以下のようなCloud Storageバケットを用意しました。上記のファイルを作成したら、deploy.shを実行してジョブをデプロイします。実行コマンドは以下です。デプロイしたジョブは、実行するとscript.shを実行するというシンプルなものです。script.shは、マウントしたバケットをlsしてログに出力するので、ログ内のデータにバケット内のファイル名が記載されていたら検証は成功です。ちなみに、マウントに成功するとCloud Run ジョブのコンソール画面でジョブのボリュームタブに、マウントしているCloud Storageの情報が表示されるようになります。今回はgcs_bucketという名前でバケットをマウントするように設定しました。確認してみるジョブのデプロイができたら以下のコマンドでジョブを実行します。実行できたら、ジョブのログの画面でログを確認します。 lsしたたくさんの結果の中に、gcs_bucketがいました。確かにディレクトリとして扱われています。続いて、gcs_bucket内のデータがlsされているかも確認します。ちゃんとバケットに保存したデータがlsされていました。確かにCloud Storageをマウントできているようです。まとめ簡潔ですが、Cloud Run ジョブでCloud Storage FUSE機能を使い、バケットをマウントしてみました。コンテナ内にバケットをマウントできることで、ファイルの解凍処理などをシェルスクリプト等で行う場合にCloud Storageからのコピー処理やアップロード処理を実装しなくて良いのは実装負担が楽になるなと思いました。プレビューですが、早くGAになって欲しい機能です。また、今回はマウントしてみただけですが、もう少し深掘りした記事を今後書いていこうと考えています。それではまた。参考 Cloud Storage FUSE
https://dev.classmethod.jp/articles/20240624-cl-fuse/

2024-06-24 10:13:46

【[セッションレポート] Amazon.com で培われた技術による小売業システムのマイクロサービス化と顧客体験向上のツボ (AWS-55)】
AWS Summit Japan 2024 にて、「Amazon.com で培われた技術による小売業システムのマイクロサービス化と顧客体験向上のツボ」を受講しました。本レポートでは、セッションで講師の方がお話された内容を、記憶を頼りに多少意訳させていただいて書きます。アジェンダユニファイドコマースリテールイノベーションコンポーザブルコマースこれらがキーワードになっているセッション内容でした。ユニファイドコマースに至った歴史シングルチャネル → マルチチャネル → オムニチャネル → ユニファイドコマース EC等が始まってマルチチャネルになったが、当初それぞれのチャネルが独立しており連携できてない状態だった。オムニチャネルでは、店舗、ECなど、どのチャネルでも共通した顧客体験を提供。ユニファイドコマースでは、デジタル世界と実店舗の世界の融合が実現される。コマースシステムの全体像フロントエンド EC, SNS, POS...といった消費者との接点バックオフィス倉庫、店舗、ERP... コマースコアフロントエンド、バックオフィスから利用される共通基盤。注文、決済、出荷... （コマースコア部分は、バックエンドと呼ぶこともあると思います）生成 AI によるデジタル体験の向上 Amazon.com のレビュー欄は、単にユーザーの投稿したレビューをそのまま表示するのではなく、 AI でレビューコメントを分析し、重要なところを強調して表示します。スマートストアテクノロジー Amazon 社がこれまでに開発したもの。 Just Walk Out Amazon GO Dash Cart ショッピングカートに商品を入れるとカメラで商品を読み取ってくれる Amazon One Enterprise 手のひら認証 Amazon One Enterprise Amazon One が、最近ついに日本に上陸しました。手のひら認証は、手をかざすだけ。カードを出さなくてよいし、QRコードを出さなくて良い。顧客体験が良いです。精度がとても高いです。99.999999%。手のひらの画像データは端末には残らないので、安全です。リテールビジョン分析 EC では顧客による操作を記録して顧客の行動分析ができる。同等のことを店舗でもやりたい。店舗内のカメラ動画からリアルタイムで解析データ（棒人間のような形）を作成して、解析する。これにより、棚から商品を取ったり戻したり、といった行動を把握できる。デジタルサイネージ店内のデジタルサイネージに AI を使って状況に応じて動的に商品を表示して、購買喚起できる。また広告場所として売ることもできる。コマースシステムフレームワーク小売事業者としては 1 - 4 の部分は、SaaSなどで調達して、「 5. フロント」の開発に注力したいはず。コマースシステム革新における挑戦コマースシステムの課題として、 POS, EC, モバイルアプリが連動しておらず、統一的な体験を提供できない（オムニチャンネルが実現できていない）。 EC パッケージもあるが、自社にちょうどいいパッケージは無い。機能が過剰で使いきれなかったり、自社仕様でカスタマイズが必要だったり。コマースシステムは大規模なので、容易に刷新できない。ゆえに意思決定に時間がかかるフロントを改善したいが、スピーディーにできない。顧客体験を素早く改善できない。コンポーザブルコマース実現に向けてマイクロサービスになっていて、豊富な選択肢のサービスがあり、API仕様が標準化されていて、他サービスに切り替えることが容易にできるなら、サービスを組み合わせて使えますね。 MACH アーキテクチャ MACH M: マイクロサービス A: API C: クラウドネイティブ H: ヘッドレス MACH Alliance API 仕様を標準化しているとのこと。 MACH Alliance […]
https://dev.classmethod.jp/articles/aws-summit-2024-aws-55/

2024-06-24 08:20:00

【블로그 릴레이 ~ ec2 인스턴스의 SSH 접속의 작동 방법을 알아봤다】
안녕하세요! AWS 사업 본부의 임채정입니다. 본 블로그는 당사의 한국어 블로그 릴레이의 두 번째 블로그입니다. 이번 블로그의 주제는「ec2 인스턴스의 SSH 접속의 작동 방법」입니다. EC2 인스턴스를 생성할 때 키페어를 설정하면 ssh 접속을 할 때 그 키페어를 사용해서 접속을 합니다. 키페어를 사용해서 접속한다는 정도만 알고 있었는데 실제로는 그 키페어가어떤 작동을 하고 있는 건지 궁금해져서 알아봤습니다. 키페어 생성 먼저 인스턴스를 생성하기 전에 키페어를 생성합니다. 키페어란 EC2 인스턴스에 연결할 때 자격 증명 입증에 사용하는 보안 자격 증명 집합입니다. 리눅스는 SSH 접속 시에, 윈도우는 RDP 접속 시에 필요한 로그인/비밀번호의 취득을 위해 사용됩니다. 키페어는 퍼블릭 키와 프라이빗 키로 구성되는데 퍼블릭 키는 데이터를 암호화하는 데 사용되고, 프라이빗 키는 데이터를 해독하는 데 사용됩니다. ① 키 페어 생성 블로그에서는 접속 […]
https://dev.classmethod.jp/articles/korean-blog-relay-lim-ec2-ssh-works/

2024-06-24 08:16:54

【Network Load Balancer (NLB)の DNS 解決設定とは】
困っていることマネジメントコンソールから NLB の「ロードバランサー属性を編集」画面を開くと、DNS 解決設定として「パブリック DNS」と「Route 53 Resolver」の二つが選択できますが、それぞれの動作の違いを教えてください。どう対応すればいいの？「パブリック DNS」と「Route 53 Resolver」は画面左側の各 DNS アフィニティー毎の動作を図示しているだけであり、選択した内容で NLB の設定が変更されるものではございません。 DNS アフィニティーの設定を検討する際の参考情報としてのみご参照ください。補足 DNS アフィニティーとは Route 53 Resolver 経由で NLB の名前解決を行ったクライアントに対し、そのクライアントが存在するアベイラビリティーゾーン(AZ)上にある NLB の IP を優先して返す様に出来る設定が DNS アフィニティーになります。レイテンシへの影響や追加料金が伴う AZ 間通信を抑制できる可能性がありますので、構成によって設定の有効化をご検討ください。なお、設定可能な値は以下の三種類となっています。アベイラビリティーゾーンのアフィニティ呼び出し元クライアントと同じ AZ にある NLB のIP を 100% で返す設定になります。同 AZ 上に正常な NLB が存在しない場合は、他の AZ の NLB の IP が返されます。部分的なアベイラビリティーゾーンのアフィニティ呼び出し元クライアントと同じ AZ にある NLB のIP を 85% で返しますが、残りの 15% は他の AZ の NLB が返ってくる可能性があります。任意のアベイラビリティゾーンデフォルトの名前解決動作です。全ての正常な AZ の NLB の IP が返却される可能性があります。( 名前解決に Route 53 Resolver を利用しない場合は全てこの動作になります) 参考資料アベイラビリティゾーン DNS アフィニティー
https://dev.classmethod.jp/articles/tsnote-nlb-dns-affinity/

2024-06-24 08:13:46

【인스턴스에 저장된 퍼블릭 키가 변경되서 접속이 안될 때 EC2 Instance Connect API를 사용한 대응법】
안녕하세요. 임채정입니다. 이번 블로그에서는 EC2 Instance Connect API를 사용해서 SSH 접속해보는 방법을 정리했습니다. 아래 블로그에서 키페어를 통해 SSH로 접속할 때의 동작 방법에 대해 정리를 했었는데, 이 때 인스턴스 안에 있는 퍼블릭 키가 변경되었을 때 어떻게 되는지도 같이 테스트해봤습니다. 변경한 후에는 퍼블릭키를 통해 암호화를 복호화할 수 없었기 때문에 인스턴스에 접속이 불가능하게 됐습니다. 궁금하시면 아래 블로그를 참고하세요(번외3) ↓ 물론 퍼블릭 키가 쉽게 변경되거나 하지는 않겠지만 혹시 변경되었을 때에는 새롭게 인스턴스를 생성해서 기존 인스턴스의 EBS를 할당하는 등의 대응법이 있습니다. 이번 블로그에서는 EC2 Instance Connect API를 사용해서 인스턴스를 변경하지 않고 기존의 키페어를 그대로 사용할 수는 대응법을 정리했습니다. 검증 환경 인스턴스 이름: test-server OS: Amazon Linux 2023 인스턴스 유형: t2.micro (테스트) 키페어: test-key 세큐리티 그룹 […]
https://dev.classmethod.jp/articles/lim-ec2-keypair-publickey/

2024-06-24 07:16:56

【ログイン時にYubikey認証後「Unauthorized」画面が表示される際の対処法】
困っていること「IAM ユーザーとしてサインイン」の画面でサインインした後、Yubikeyの認証を設定しています。認証を行うと、「Unauthorized」といった画面が表示されます。「sign in again」をクリックすると無事にマネージメントコンソールに入れますが、この画面を表示させないようにするにはどうしたらいいのでしょうか？どう対応すればいいの? 基本ですが、ブラウザのキャッシュ/ Cookie のクリアを行って解消するか確認します。またブラウザのプライベートモード/シークレットモードの操作で、解消するかどうか試します。そして、サインイン時の URL に以前にサインインした際の情報が含まれていてエラーになるケースもあります。URLも以下のもので試してみて、事象が改善するか試してみます。 https://My_AWS_Account_ID.signin.aws.amazon.com/console/ こちらに、「リダイレクトによってサインイン URL が不明確になる」と明記されています。終わりに Yubikeyを利用する場合、利用しない場合でも、ログインの際同じエラーメッセージでも状況が変わるようです。この記事がどなたかのお役に立てば幸いです。
https://dev.classmethod.jp/articles/what-to-do-when-the-unauthorised-screen-appears-at-login/

2024-06-24 07:13:46

【Swift ConcurrencyとNEHotspotConfigurationでシンプルなWi-Fi接続を実装する】
現在開発中のアプリで、QRコードを読み込み、Wi-Fi接続をする必要があった。Wi-Fi接続をアプリに組み込むために、iOS 11から導入されたNEHotspotConfigurationとNEHotspotConfigurationManagerを使った。 NEHotspotConfigurationとNEHotspotConfigurationManagerの使い方については、以下の記事でSINさんが解説しているので詳細については割愛する。 NEHotspotConfigurationとNEHotspotConfigurationManagerを使うことで、アプリはユーザーの手を借りずに特定のSSIDに接続できる。本記事ではSwift Concurrencyを使ってより簡単にWi-Fiホットスポットに接続する方法を紹介する。 1. NEHotspotConfigurationの設定指定されたSSIDおよびパスフレーズを使ってWi-Fiネットワークに接続する。この関数では、NEHotspotConfigurationを作成し、それをNEHotspotConfigurationManagerを通じて適用する。パスワードが提供されている場合は、WPA/WPA2用の設定を作成し、そうでない場合はオープンネットワークの設定を作成する。 Swift ConcurrencyのwithCheckedThrowingContinuationを使って非同期のエラー処理を行う。これにより、NEHotspotConfigurationManagerのapplyメソッドの完了ハンドラーを非同期に処理できる。 NEHotspotConfigurationErrorのエラーリスト Wi-Fiの接続時になんらかの問題が発生するとエラーが投げられる。この関数から投げられるエラー NEHotspotConfigurationError は下表の通り。エラー説明 invalid 無効な設定 invalidSSID 無効なSSID invalidWPAPassphrase 無効なWPAパスフレーズ invalidWEPPassphrase 無効なWEPパスフレーズ invalidEAPSettings 無効なEAP設定 invalidHS20Settings 無効なHS20設定 invalidHS20DomainName 無効なHS20ドメイン名 userDenied ユーザーが許可しなかった internal 内部エラーが発生した接続ダイアログでキャンセルをクリックすると userDenied エラーが投げられる。他のエラーと異なりユーザーが自身で選択して発生させたエラーのため、エラーダイアログを表示させないなどの工夫をすることでユーザーにとって使いやすいアプリになるだろう。詳細な説明はこちらを参照。 2. Wi-Fiへの接続上記のconnectToWiFi関数を利用して、特定のSSIDに接続するには、以下のようにパラメータを指定して実行する。 3. ホットスポット構成の削除特定のSSIDの構成を削除するには、以下のようにremoveConfigurationを実行する。 Wi-Fi接続情報のQRコードフォーマット Wi-Fiネットワークの設定をQRコードで提供する場合のフォーマットはある程度規格化されているようだ。以下のような形式のQRコードをスキャンすると、デバイスをWi-Fiネットワークに接続できる。詳細はこちらを参照。例: WIFI:T:WPA;S:mynetwork;P:mypass;H:false;; フォーマット例： WPA/WPA2 Personal: WIFI:T:WPA;S:MyNetwork;P:mypassword;H:false;; WEP: WIFI:T:WEP;S:MyNetwork;P:mypassword;H:false;; オープンネットワーク: WIFI:T:nopass;S:MyOpenNetwork;H:false;; 各パラメータの説明ユーザーが簡単にネットワークに接続できるQRコードを作成できる。パラメータ説明 T 認証タイプ（例: WPA, WEP, WPA2-EAP, nopass） S SSID（ネットワーク名） P パスワード（認証タイプがnopassの場合は省略可能） H 隠しSSIDかどうか（trueまたはfalse） E EAPメソッド（WPA2-EAPの場合のみ） A 匿名ID（WPA2-EAPの場合のみ） I ID（WPA2-EAPの場合のみ） PH2 フェーズ2メソッド（WPA2-EAPの場合のみ）まとめ NEHotspotConfigurationとNEHotspotConfigurationManagerを使うことで、アプリ内から簡単にWi-Fiネットワークへの接続と切断を管理できる。Swift Concurrencyを利用することで、非同期操作がさらに簡単にできるようになった。関連記事 NEHotspotConfiguration | Apple Developer Documentation NEHotspotConfigurationManager | Apple Developer Documentation [iOS 11] NEHotspotConfigurationでWi-Fiホットスポットの構成をアプリに組み込む #WWDC17 | DevelopersIO
https://dev.classmethod.jp/articles/implementing-simple-wifi-connection-with-swift-concurrency/

2024-06-24 04:13:46

【[セッションレポート] 規模が膨らんで開発スピードが落ちてきたモノリスアプリケーションを正しく分割する方法（AWS-57） #AWSSummit】
いわさです。本記事は 2024 年 6 月 20 - 21 日の 2 日間開催された AWS Summit Japan 2024 のセッションレポートとなります。このセッション、個人的に大変興味があったものの当日は GameDay に参加しており現地で聴講することが出来ませんでした。しかしすぐにオンデマンド配信がされているではありませんか。やったぜ。オンデマンド配信の動画リンクと資料のダウンロードは以下です。動画の視聴と資料のダウンロードには AWS Summit Japan のマイページのログインが必要です。オンデマンド配信リンク - 規模が膨らんで開発スピードが落ちてきたモノリスアプリケーションを正しく分割する方法（AWS-57） AWS Summit Japan - セッション資料一覧概要 6/21(金) 14:50 - 15:30 セッションタイトル：「規模が膨らんで開発スピードが落ちてきたモノリスアプリケーションを正しく分割する方法（AWS-57）」フレームワークを活用した典型的なWeb三層のアプリケーションで開発をスタートし、最初はスピード感のある開発が行えていたのに、徐々に機能が追加されていき、気がつくと様々な機能が密結合になり、単一のデータベースを様々な機能が利用していて、変更の影響がどこにあるか分かり難くなってきます。次第に機能追加に時間がかかるようになり、古いコードを変更することが怖くなり、元のコードを残したまま、コードを追加するようになって益々複雑化していきます。このような状況を改善するためには適切な粒度でサービスを切り出して置き換えていくことが必要です。では、どのようにすれば正しい粒度でサービスを分割ができるでしょうか。本セッションでは DDDをベースとしてEvent Storming を活用した境界づけられたコンテキストの発見による具体的なサービスの分割方法をご紹介します。スピーカー福井厚アマゾンウェブサービスジャパン合同会社プロトタイプ＆カスタマーエンジニアリング本部 Developerスペシャリストソリューションアーキテクトレベル Level 400: 上級者向けアジェンダなぜリアーキテクチャが必要になるのか？どうやってサービスを分割するのかドメイン駆動設計とイベントストーミングによる分割非機能要件を論理アーキテクチャにマッピングドメインモデルをインフラストラクチャコードから分離セッションレポートちなみにこのセッションはほとんど AWS の話出てこないです。最後に API Gateway - Lambda - DynamoDB の場合にクリーンアーキテクチャを当てはめるところで例で出てくるくらいでしょうか。実際にマイクロサービス化を進めるにあたっては AWS サービス云々よりも前段階が非常に難しくそこで失敗することが多いのでは、むしろ非 AWS 領域にフォーカスしたこのセッション内容は多くの方が聞きたいことなのではないでしょうか。前半冒頭でまず以下の流れでマイクロサービス化の必要性についておさらいしています。よくある Web 三層アーキテクチャ・モノリスの強み小規模な開発では、フレームワークの機能によってシンプルに実装が可能ー出たベースはトランザクションで一貫性を容易に確保ビジネスロジックは単純なCRUDや、フレームワークが提供するORマッパーでの実装が中心少人数での開発に最適デプロイメントはモノリスでシンプルモノリシックアーキテクチャで成長し続けた際に出てくるつらみ異なる機能から共通のデータへアクセスパフォーマンスも課題に利用者が増えてくるとスケーラビリティの確保が必要モノリスだとスケール単位もモノリスになり、スケールしなくても良いものまでスケールしてしまうアプリはスケールアウトして負荷分散しやすいが、データベースに負荷が集中する。また、データベースはスケールアップ戦略を取ることが多いが、上限があることが多いビジネスロジックが他のレイヤーに漏れ出していってしまうコードの見通してが悪くなり、機能追加や修正が及ぼす影響が不明に共通ライブラリの修正による影響が大きくなるデータベーススキーマの変更が他の機能に影響を与えるデプロイメントが大変になりリリース頻度が低下するマイクロサービスアーキテクチャ採用理由デプロイの影響範囲を小さくする機能的な自律性と単一責任の原則開発速度の向上スケーリングの最適化コストの最適化やめたほうが良いケース […]
https://dev.classmethod.jp/articles/aws-summit-2024-aws-57/

2024-06-24 03:26:26

【pyotpでワンタイムパスワードを試してみる】
はじめにデータアナリティクス事業本部のkobayashiです。 Pythonで2FAやMFA用のワンタイムパスワード（OTP: One-Time Password）を生成および検証するためのライブラリを試してみたのでその内容をまとめます。 pyauth/pyotp: Python One-Time Password Library qrcode · PyPI pyotpとは pyotpはOTPの生成と検証を行うことができるライブラリで、TOTP（Time-base One-Time Password）とHOTP（HMAC-based One-Time Password）の両方を扱うことができます。実装は非常に簡単に行えますが公式ドキュメントにもある通り認証の核になるものなので組み込む際にはチェックリストの内容に従う必要があります。 Implementers should read and follow the HOTP security requirements and TOTP security considerations sections of the relevant RFCs. At minimum, application implementers should follow this checklist: pyauth/pyotp: Python One-Time Password Library pyotpではTOTPとHOTPの2種類がありますが次のようにに使い分けます。 TOTP（Time-base One-Time Password）指定された時間でOTPを更新する。Google Authenticatorや1PasswordなどのOTPクライアントアプリで生成されたOTPを認証に使う。 HOTP（HMAC-based One-Time Password）カウンターでOTPを更新する。e-mailやsmsでOTPが送られてきたOTPを入力して認証を行う。 pyotpを試してみる今回はGoogle Authenticatorを使うTOTPを検証してみます。環境 Python 3.11.8 pyotp 2.9.0 qrcode 7.4.2 実装してみるはじめにpyotpをインストールしますがこれはいつも通りpipでインストールできます。またqrコードを作成するバッケージも一緒にインストールします。今回は以下の流れで実装してみます。鍵を作成する（get_secret_key関数）作成した秘密鍵を環境変数に保存し、その秘密鍵でTOTPオブジェクトを作成してからOTPクライントアプリで読み込めるQRコードを作成する（get_qr関数） OTPクライアントアプリで発行したOTPを検証する（confirm_totp関数）以下がソースコードになります。それでは早速試してみます。まずはじめにOTPで使用する鍵をpyotpパッケージで作成します。次にOTPクライアントで読み込むためのQRコードを作成します。環境変数OTP_SEC_KEYに保存しQRの発行とOTPの検証にこの環境変数を使います。本来の使い方としてはこの鍵をユーザーのパスワードと同様に取り扱いDBなどに保存して使うべきですが、今回はあくまでpyotpの検証なので簡易に環境変数に保存して使っています。実行するとotp.pngのファイルが作成されるので開くと以下のようなQRコードが表示されます。今回MFAクライアントとしてGoogle Authenticatorで読み込むと以下のようなOTPが作成されます。では最後にGoogle Authenticatorで表示されるOTPを検証してみます。このようにMFAクライアントで生成されたOTPを検証するとTrueを返し、適当な6桁の数字を入れたり有効期限が切れるとFalseとなることがわかります。まとめ OTPを生成および検証するためのライブラリpyotpを試してみました。特に難しいことなく公式ドキュメントに記載されている方法で実装することで少ないコードでOTPの仕組みを使うことができました。認証が必要なWebアプリにも簡単に組み込めるかと思います。最後まで読んで頂いてありがとうございました。
https://dev.classmethod.jp/articles/pyotp/

2024-06-21 17:16:56

【Claude 3.5 Sonnet、Anthropic社の最新生成AIモデルを試してみた】
2024年6月20日、 Anthropic社の最新生成AIモデル「Claude 3.5 Sonnet」が Amazon Bedrock で利用可能になりました。今回、Amazon Bedrock で Claude 3 Opus に匹敵する性能を、1/5のコストで利用できるとされる、Claude 3.5 Sonnet を試す機会がありましたので、紹介させていただきます。 Bedrock 記事執筆時点で Claude 3.5 Sonnet がリクエスト可能となっていた、バージニア(us-east-1)リージョンを利用しました。モデル有効化「Modify model access」より、 Claude 3.5 Sonnet の選択をチェック。確認画面を経て、モデルを有効化しました。従来のモデル同様、数分でアクセスのステータスは「アクセスが付与されました」となり、 Claude 3.5 Sonnet が利用可能になりました。動作確認チャットのプレイグラウンドを利用して、次のAWSサービスの特徴と、ユースケースの問い合わせを試みました。プロンプト解析対象の画像動作画面結果モデル別の応答結果は以下の通りでした。 Claude 3.5 Sonnet Claude 3 Opus Claude 3 Sonnet モデルメトリクス比較メトリクス Claude 3.5 Sonnet Claude 3 Opus Claude 3 Sonnet レイテンシー 21728 ms 33579 ms 11096 ms 入力トークン数 7778 1049 1049 出力トークン数 818 533 453 まとめ Claude 3.5 Sonnet、 2024年3月にリリースされた先代の Claude 3 Sonnetから更に進化を遂げました。今回は簡単な画像解析でしたが、他のユースケースについても進化を確かめてみたいと思います。また、今後の Claude 3.5はハイエンドモデルの「Opus」、軽量、高速、廉価に利用できる「Haiku」のリリースも予定されているとの事で、そのリリースも心待ちにしたいと思います。
https://dev.classmethod.jp/articles/claude-35-sonnet-new-anthropic-ai-model/

2024-06-21 15:13:46

【[ブースレポート]AIによるプラント保守の伝承】
はじめにこんにちは大阪オフィスのよなです。本記事は2024年6月20~21の2日間で開催されたAWS Summitのブースレポートです。個人的にすごく面白い！と思ったブースについて書きたいと思います！私の主観も結構入ってるのでその点はご了承ください。概要テーマ：IoT, 生成AI ブースタイトル：「AIによるプラント保守の伝承」 Amazon Web Services ブログでも以下のブログが紹介されています。一部、上記のブログより画像を引用させていただいております。アジェンダプロセス製造業でどのように生成AIが活用できるのか？ということを製造現場を模したデモ機を用いて紹介されていました。具体的には、ベテランエンジニアが持つノウハウをデータ化することで、新人や経験の浅いエンジニアもAIを使ってベテランのノウハウを活かすことができるという内容でした。プロセス製造業に限らず、製造業や機器メーカーでも共通の課題を持っている企業は多いと思うので、幅広く参考になる内容だと思いました。私自身クラスメソッドにジョインするまでは機器のメンテナンスなどに従事していたこともあり、とても興味を持てる内容でした。デモの全体像それではまずデモの全体像です。以下の図と説明部分はAWSブログを引用させて頂いております。オペレータは現場から発報されたアラートを確認する。オペレータは生成AIチャットボットに問い合わせする。チャットボットは過去のレポートを元に原因・対処方法と、推奨される現場への確認アクションを応答する。オペレータは現地エンジニアにリモート通話で、AI から生成された応答を基に状況確認を依頼する。現地エンジニアは実際の状況を確認後、対応作業を行う。もし原因究明や解決が困難な場合は、別途ベテランエンジニアに通話に入っていただく。対処が完了した場合、原因や対処法などをレポートに記載し保存する。デモンストレーショントラブル発生今回のデモでは液体を水槽Aから水槽Bに送液する装置でトラブルが発生した場合のデモンストレーションが行われていました。まずは異常状態として攪拌機にかかる電圧を下がることで期待する攪拌結果が得られい状況を作ります。この異常な状態を検知してオペレータへアラートが発報されます。次にオペレーターは異常が発生した原因を調査します。ベテランと新人原因調査のプロセスではベテランと新人に大きな差が生まれます。ベテランは自身の経験から、エラーの原因、確認するべき点、確認方法、対処方法、対処の優先順位などを頭の中で想像しながら効率よく作業を行います。対して新人はエラー内容をマニュアルで調べて、確認箇所を調べて、確認の方法を調べて...というように一つずつ「探す、調べる」という行為が発生します。通常、機器は複数の部品の組み合わせで構成されています。そのため、多くのマニュアルやメンテナンスログと睨めっこしながら1つずつ原因を潰していくのは非常に時間がかかる作業です。生成AIを活用した原因調査そこで生成AIが活躍します。生成AIを用いて蓄積されたノウハウというデータベースを自然言語で検索できるようにします。具体的にはRAGを使ってマニュアルやメンテナンスログなどを検索することで、AIがあたかもベテランエンジニアのアドバイスのような回答をしてくれます。今回のデモでは下の画像のように、エラー内容から考えられる原因、過去に同じエラーが出た際の対処方法などが出力されていました。これってめちゃくちゃすごいことなんです！！実際にマンパワーでこの情報を揃えるには、エラー内容をマニュアルで探す過去のメンテナンスログから似た症状が発生していないか探す過去の解決方法から最適な解決方法を探す対処方法の手順を調べる他の要因がないか調べるなどなど、他にも考えるべきことは多岐にわたります。私も以前、機器のエンジニアとして働いていた時は、分厚いキングファイに挟まれたメンテナンスマニュアルと過去のメンテナンスログから可能性の高そうな箇所を探すことにかなり時間を取られることがありました。これを自然言語で解決できるなんて感動しますよね！トラブルシューティング次に生成AIの回答を元に現場の作業者へ指示を出します。ここのオペレーションは今まで新人がベテランに聞く。というフローとあまり変わらないように思います。しかし、ベテランの時間を割かなくても解決できる可能性があるというのはお互いにとって非常に良いことですね。また、トラブルが1度で解決しないことも多いので、そこでもAIを使って自然言語で解決までの手助けをしてくれるのはありがたいですね。トラブル解決後は必ず確認作業がつきものです。確認作業に関してもマニュアルや過去の作業履歴を参考にステップバイステップで教えてくれると作業の効率化につながると思います。今回のデモでは遠隔でオペレータが指示をする想定でしたが、現場の人が生成AIを使って作業するというようなケースでも活躍しそうですね。デモの中でも解説がありましたが、新人+AIでは解決できずにベテランに頼って解決できた場合でも、そのデータを残すことで次回以降にAIが参照するデータソースになります。このように、新たな情報もどんどんデータとして残すことで将来的な作業効率化につながります。感想ベテランと新人を比べましたが、たとえベテランエンジニアでも情報を探すのには時間がかかるものです。その調べるという行為を短縮できるのは誰にとってもメリットになるのではないでしょうか。ただし、こういったAIの活用にはソースとなるデータが不可欠です。そのために以下のことが非常に重要だと思います。エンジニアがなるべく手間をかけずに作業データを保存できる仕組みベテランのノウハウを言語化、データ化する紙ベースのデータをAIのデータソースとして使える形式に変換するまだまだ現場ではベテランの頭の中にのみ貴重な情報がある状態や、紙ベースで情報が管理されていてデータとして扱えないケースも多いのではないかと思います。昨今はエンジニアの確保も難しくなってきているので、技術を活かしてひとりひとりの作業効率を上げていくことが求められているように思います。そのめにも、まずは活用できるデータを蓄積して、うまく利用していくことが重要だと改めて感じました。全体を通してとても楽しく、今後こういった技術が増えてくることが期待できるとてもいい内容でした！
https://dev.classmethod.jp/articles/%e3%83%96%e3%83%bc%e3%82%b9%e3%83%ac%e3%83%9d%e3%83%bc%e3%83%88ai%e3%81%ab%e3%82%88%e3%82%8b%e3%83%97%e3%83%a9%e3%83%b3%e3%83%88%e4%bf%9d%e5%ae%88%e3%81%ae%e4%bc%9d%e6%89%bf/

2024-06-21 14:13:46

【【7/18（木）リモート】猫好きエンジニア向け会社説明会を開催します】
猫ちゃん好き！技術好き！なエンジニア向けの会社説明会です！クラスメソッドには猫好きな多数のエンジニアが在籍し、日頃から猫とIT技術を愛でながらいきいきと働いています！そこで、今回はいつもと少々趣向を変えまして、「猫好きエンジニア」に特化した会社説明会を開催いたします。本会社説明会では、クラスメソッドのエンジニアはどんな仕事/働き方をしているか？クラスメソッドのカルチャー/社風などをお伝えすることはもちろん、猫好きクラスメソッド社員は日頃からどのように猫と仕事の両立をしているのか？猫好きクラスメソッド社員はどのような技術に興味を持っているのか猫好きエンジニアがクラスメソッドに入社するべき理由！などなど、猫とクラスメソッドについてざっくばらんにお話しさせていただきます！今回の会社説明会では、Slido（https://www.slido.com/jp）を使用しながらご参加いただきます。皆様とインタラクティブにやり取りしながら進行させていただきます。猫ちゃんについて・クラスメソッドについて・働く環境などなど、質疑応答のお時間にいただいた質問へお答えさせていただきます。会社や猫や技術に関することなど、お気軽にコメント・ご質問いただけますと嬉しいです！ Zoomウェビナーでのリモート開催となります。全国各地からご参加可能でございますので、皆様のご参加を心待ちにしております！お申し込みはこちらこんな方が対象です猫ちゃんとIT技術が大好き！猫ちゃんとの暮らしを大切にしながらも技術力を磨きたいクラスメソッドの働く環境を知りたい技術好きな仲間と一緒に働きたい新しいことへの挑戦ができる環境で仕事をしていきたい参考ブログ記事（抜粋） Lambda(Go)で猫のエネルギー供給量を計算するAPIを作ってAPI Gatewayでテストしてみた【初心者向け】Google Apps ScriptでSlackへ猫画像を届けてみた開催概要開催日時 2024年7月18日（木）19:00〜20:00 募集締切日 2024年7月18日（木）※定員に達した場合、早めに締め切る場合があります会場リモート（Zoom）開催定員 50名（先着順） ◆リモート開催◆ Zoomウェビナーでの開催を予定しております。会社説明会のご参加URLはお申し込み後、メールにてURLをお知らせいたします。初めてZoomをご利用になる方は、ソフトウェアのインストールが必要です（所要時間1〜2分）。（ご参考）Zoomとは https://zoom.us/jp-jp/meetings.html タイムテーブル時間内容登壇者 18:45 - 19:00 受付 - 19:00 - 19:10 挨拶・猫とクラスメソッドについて人事労務室採用チーム足立しほり 19:10 - 19:25 登壇者自己紹介・猫ちゃん紹介・登壇社員共に社員が飼っている猫ちゃんのご紹介です。 AWS事業本部コンサルティング部川原征大 AWS事業本部　サービス開発室べこみんデータアナリティクス事業本部サービスソリューション部クルトン 19:25 - 19:35 テーマセッション１猫との暮らしとクラスメソッドでの仕事の両立・クラスメソッド社員が日頃どのように猫ちゃんとの暮らしと仕事を両立しているかお話しします。同上 19:35 - 19:50 テーマセッション２猫好きエンジニアが選ぶ！おすすめDevIO記事・猫好きエンジニアの観点から選ぶおすすめのDeVIO記事をご紹介します。同上 19:50 - 20:00 質疑応答 ALL セッションの内容や順番、スピーカーは変更になる可能性があります。本イベントは一部録画を行い、後日アーカイブ動画を公開予定です。各登壇者が発表した内容は後日ブログ等で公開する可能性があります。皆様のプライバシーは担保いたしますのでご安心ください。お申し込みフォームお申し込みはこちら ※お申し込みいただきますと自動返信メールが届きますので、詳細確認をお願いします。 ※迷惑メール対策やドメイン指定受信等を設定している方は、【@classmethod.jp】からの確認メールが受信されますよう、ご確認ください。クラスメソッドについて数字でわかるクラスメソッド就職せずに自己資本でクラスメソッドを起業して16年掛けて年商200億円になった話テレワークでも100%パフォーマンスを出すための企業カルチャーの作り方採用記事クラスメソッドで描けるキャリアクラスメソッドの人事が採用時に重要視しているポイント募集ポジション
https://dev.classmethod.jp/news/jobfair-240718-1/

2024-06-21 12:20:06

【【セッションレポート】インシデントの影響を封じ込めるクラウドアーキテクチャの実践（AWS-58）#AWSSummit】
はじめに AWS Summit Japan 2024 に参加しました。「インシデントの影響を封じ込めるクラウドアーキテクチャの実践」のセッションレポートです。セッション概要障害の影響範囲を抑えてシステムのレジリエンスを向上させる方法に関する Deep dive セッションです。マルチテナントの SaaS 環境でも広く使われており、AWS や Amazon が障害を隔離する際の戦略に採用している Cell-based architecture や Shuffle Sharding のテクニックについてご紹介します。併せて、これらを実装する上での技術的な課題や考慮点についても触れます。取り扱い内容セルベースアーキテクチャの効果セルベースアーキテクチャの設計ポイント追加手法：シャッフルシャーディングセッションレポートウェブアプリケーションの紹介事例3つシナリオ1：コスト削減のため、不要になったDynamoDBの属性を一部削除した障害原因：実はアプリ内に残っていた依存関係があり障害がおきた対策案：テストを行い切り戻しできるようにしておくしかし、全てのシナリオをテストすることは非現実的シナリオ2：ある機能の挙動がおかしいので、切り分けのためにポートをあける作業を行った障害原因：セキュリティグループのルール変更ではなく、ルールの削除をしてしまい障害がおきた対策案：本番環境は、手動では触らない。IaCやCI/CDを用いるミスを完全に防ぐのは難しいシナリオ3：特定のユーザーが想定していないデータ型/頻度のリクエストを送ってきた（Poison pill）障害原因：バグを踏んで障害を発生対策案：テストやスロットリング全てを想定することは難しい３つのシナリオに共通するのが、全ての可能性を予測しつつ防ぐのは難しい。障害の範囲が全体であることが問題。セルベースアーキテクチャで障害の影響範囲を小さくするのが有効的であるセルベースアーキテクチャとはアプリ全体をセル単位で複製し、論理的な境界を作成する手法データプレーンセル：独立したアプリケーションセルルーター：リクエストを振り分けコントロールプレーンセルの作成や削除、データ移動を行うセルベースアーキテクチャのメリット障害分離性：障害の影響を全体のうち一部に抑えられる一般の構成：Poison pillで障害影響が全体に及ぶ可能性が高いスケール性：セルを追加することでスケールできる挙動が予想しやすくなる一般の構成：スケールアップが中心。サービス規模が大きくなることで発生する障害を受けるテスト性：特定のセルのみに変更が適用できるため、テストしやすい一般の構成：ブルーグリーンの影響は全体に影響があるセルベースアーキテクチャを導入した場合、障害のシナリオを防ぐことができるセルベースデメリットハードウェア故障確率が増加する可能性があるセルの数だけ増える自動復元で対策可能複雑性とコストが増える自動化が一定の対策になる EBSでも採用されている事例 EBSのプライマリストレージは、セカンダリストレージにも書き込まれるプライマリの情報を「設定情報サービス」から取得することで整合性を保つ設定情報サービスの復元力が重要である処理の流れは以下の通り。クライアントは設定情報サービス内のセルルーターに問い合わせるセル情報を取得セルへプライマリ情報を取得セルベースアーキテクチャ導入後、設定情報サービスの可用性が向上した。ここまでのまとめセルベースアーキテクチャとは、アプリ全体をセル単位で複製し論理的な境界を作成する手法 Poison pillなどの障害の影響範囲を1つのセルに封じ込めることができるスケール性やテスト性のメリットもある予期せぬ障害に対する対策が必要な重要サービスで効果的であるセルベースアーキテクチャの設計ポイントセルベースアーキテクチャの主要設計ポイント３つセルルーターセルコントロールプレーンセルルーターセルルーターの機能と特性データ分割に利用されているパーティーキーがどのセルにマッピングされているかを保持する共通コンポーネントのため、高い可用性とスケーラビリティが求められる可能な限りシンプルにすることテスト不足や障害モードを減らすセルルーティングの方法：DNSパターン DNSに対してどのセルに行くべきか問い合わせて、返ってくるIPでアクセスする方式 Route 53はSLA 100% パーティションキーが利用できる場合は有用クライアント側で持っている情報とDNS名をマッピングのために、クライアント処理を追加する場合があるマッピングが許容できない場合、API Gatewayパターンを利用検討するセルルーティングの方法：API Gatewayパターン API GatewayをDynamoDBのプロキシとして利用する API Gatewayの機能が利用可能というメリットがある SLAを鑑みて、必要に応じてマルチリージョン化する高い柔軟性が求められる場合、コンピュータ層パターンを利用する […]
https://dev.classmethod.jp/articles/aws-summit-tokyo-2024-session-report-aws-58/

2024-06-21 12:16:56

【【7/18（木）リモート】猫好きエンジニア向け会社説明会を開催します】
クラスメソッドでは、AWS・モバイル・ビッグデータ・IoT・SaaSなどの技術職や営業のメンバーとして一緒にお仕事をする仲間を大募集しています。
https://dev.classmethod.jp/news/jobfair-240718/

2024-06-21 12:13:46

【Cloud Run ジョブのジョブ実行キャンセルに関する権限が変更になります】
概要 2024年9月16日から、Cloud Run ジョブのジョブ実行のキャンセルに必要なIAM権限が現在のrun.jobs.runからrun.executions.cancelという新しいIAM権限に変更となります。現在はCloud Run ジョブの実行（jobs.run APIメソッド）とジョブ実行のキャンセル（executions.cancel APIメソッド）の両方に、同じIAM権限であるrun.jobs.runが使用されています。これが2024年9月16日から変更になります。 ※実行の権限は2024年9月16日以降も変わらずrun.jobs.runのままです。現在 2024年9月16日以降ジョブのキャンセル run.jobs.run run.executions.cancel ジョブの実行 run.jobs.run run.jobs.run What you need to know Currently, Cloud Run uses the same IAM permission, run.jobs.run, to control access to both running a job (the jobs.run API method) and canceling a job execution (the executions.cancel API method). To give you greater flexibility in defining custom roles, we are changing the IAM permission required for canceling a job execution (the executions.cancel API method) to a new IAM permission named run.executions.cancel. 現在、Cloud Runでは、ジョブの実行（jobs.run APIメソッド）とジョブの実行のキャンセル（executions.cancel APIメソッド）の両方のアクセスを制御するために、run.jobs.runという同じIAMパーミッションを使用しています。カスタムロールをより柔軟に定義できるように、ジョブの実行のキャンセル（executions.cancel APIメソッド）に必要なIAMパーミッションを、run.executions.cancelという新しいIAMパーミッションに変更します。(DeepL翻訳) ※引用：[Action Advised] Update your IAM roles to cancel Cloud Run jobs 対応する必要があるかどうか使用しているIAMユーザやサービスアカウントに付与しているロールによっては対応が必要になる可能性があります。以下の表は、ジョブの実行をキャンセルするというアクションを行う際に用いているロールによって対応する必要があるかどうかをまとめたものです。使用ロール対応要否 run.jobs.runを使用しているカスタムロール必要 […]
https://dev.classmethod.jp/articles/20240621-cloudrunjobs-rc/

2024-06-21 11:16:56

【[内製化支援] 内製化支援のグループコーチングをドッグフーディングして見えたもの】
情報システム室の進地@日比谷です。 2024年に入ってから、約半年ほどCX事業本部の内製化支援サービスをドッグフーディングさせていただく機会がありました。支援対象は私が所属する情報システム室コアシステムチームになります。内製化支援を受けた背景手前味噌ではありますが、私達のチーム、コアシステムチームはとても良いチームであると思っています。皆、自律的に動けるプロフェッショナルですし、性格も皆穏やかで、安心してお互いに意見を述べ合うことができます。客観的にみて、心理的安全性がとても高いチームだと思います。しかし、そんなチームにも「こうなったらもっといいな。もっとデキるようになれるな」と思うポイントがあります。チームリーダーの私が思うに大きく５つのポイントがありました。チームのみんなの社内外のプレゼンスをもっと上げたい課題の優先順位づけをもっと上手くやりたいスケジュールにコミットしたいふりかえりを成長につなげたい外部の視点をチームに入れたいこうした背景、目的をもって今回、内製化支援サービスのお力を借りることになりました。内製化支援を受けて見えてきたもの私たちがドッグフーディングした内製化支援サービスは大まかに次のステップで構成されていました。ゴールの明確化（「もっとできるチームになるために何ができるか？」）内製化支援チームによる、メンバー一人一人の個別ヒアリング（STEP0）期間: 約2ヶ月グループコーチング期間: 約3ヶ月いきなり全員でグループコーチングを始めるのではなく、一人一人に向き合って認識や事実関係を丁寧に拾い、全員の目線を合わせてからグループコーチングに臨む形であったため、事実関係の認識が食い違ったまま議論が平行線になってしまうといったこともなく、建設的な意見がポンポンと出る場になったと思います。何を議論するか？その優先度はどの程度か？どうなっていれば満足と言えるのか？といったありとあらゆることを自分達の議論で導き、定義していく場であるため、内製化支援サービスが「何かを与えてくれる」という認識であった場合には面食らうかもしれません。答えを出せるのは自分達で、自分達以外にいなくて、自分達の中に充分答えを出す力はあることに気づくこと。これがもしかしたら内製化支援サービスの肝なのかもしれないと思いました。この認識に至れたチームは、その後自走できるし、故にあくまで内製化「支援」サービスなんだなと。ちょっとずつでも掃除し続けることが大事と理解ファシリテーションを受けながら、グループコーチングで自分達のありようを深掘りしていくなかで、私が感じたことは次の３つでした。既にうまくまわっていると感じている現況に対して無理に欠けている部分を探す必要はない。自分達の自己評価、実感をもっと信じていい。ファシリテーション能力は一朝一夕で身につくようなものではない。必要な時はプロに頼んだほうがいい。週に1時間、隔週に1時間で良いので、業務改善に使う固定枠の時間をとり、それを取り続けることが大事。私は自分達のチームが上手く行っていることを外部の何かに保証して欲しい、担保して欲しい、証明して欲しいとどこかで思っていたようで、そのことがグループコーチングを進めていくなかで見えてきました。でも、そんなものはないし、仮に得られたとしても何の意味もない、そのことがわかってきました。自分達が上手く行っている、充実した仕事を行えていると感じているならそれが正解だし、その感覚や実感を信じていいんだと感じました。また、ファシリテーション能力は、それだけで何冊もの本がかけてしまうほど奥深い世界であるということも感じました。素人が一朝一夕で身につけられるものではない。何気ない一言、最初の認識のすり合わせ、場の設定、同時に議論する最大人数の調整など、様々なことに気が配られていました。基本は自分達のチームで何とかするという姿勢は持ちつつも、ファシリテーションだけは必要な時は外部のプロに頼るのは最適解だと感じました。最後に、チームの外部環境も内部環境も、チーム自体も常に変化していくものであるため、最適解は常に変わっていくという認識と、とはいえ無理をしては続かないということから、週に1時間〜隔週に1時間で良いので、業務改善に使う枠をとって、それを取り続けることが大切であることも学びました。いわば、これは掃除のようなもので、掃除は掃除能力を身につけたら終わりではないし、一度行ったらもう行わなくていい類のものでもありません。続けること、少しずつでも良いので掃除し続けること。能力の問題ではなく、姿勢の問題として取り組み続けること。それが大事なことなのだと学びました。内製化支援ドッグフーディングを終えて私たちは自分達で決めていくことに自信を持つことができるようになったと思います。そして、具体的に新たに導入した習慣として、毎週1時間の業務改善の時間をとる習慣があります。チームをもっとよくするための具体的なノウハウではなく、チームをもっと良くするための道の歩き方を教えていただきました。必ずやもっと良いチームになっていくと思います。内製化支援チームの皆さん、ありがとうございました！！
https://dev.classmethod.jp/articles/things-finded-out-through-insource-support/

2024-06-21 03:13:46

【AWS Step Functionsを使ってAmazon Connectによるユーザーへの自動架電を行う】
はじめに AWS Step Functionsを使ってAmazon Connectによるユーザーへの自動架電を行う方法をまとめました。 Amazon Connectによる自動架電は、以下のようなユースケースでの利用が考えられます。システム障害発生時に運用担当者へ自動でアラート通知を行いたい予約の確認やリマインダーを自動化して業務を効率化したい新商品やキャンペーンの告知を顧客リストに自動架電で行いたい AWS LambdaとAmazon SNSを組み合わせてAmazon Connectによる自動架電を行う方法については、以下の記事が参考になります。この記事では、Amazon SNSをトリガーにしてAWS Lambda経由でアウトバウンドコールを行っています。今回は、Step Functions ステートマシンを起点に、Amazon Connectによる自動架電の方法をまとめました。 AWS LambdaではなくAWS Step Functionsを利用することで、以下のようなメリットがあります。ワークフローをグラフィカルなインターフェースで定義できる複雑なロジックをコーディングせずに実装できる並行処理や条件分岐、エラー処理などを簡単に実装できる Step Functions ステートマシンを起点にしますが、Step Functions ステートマシンを呼び出すAWSサービスは、以下の通り多くあります。 AWS Lambda Amazon API Gateway Amazon EventBridge AWS CodePipeline AWS IoT ルールエンジン AWS Step Functions Amazon EventBridge の一機能である Amazon EventBridge Pipes でも、ターゲットをStep Functionsに設定することが可能です。ソースは以下が選択できます。 Amazon DynamoDB Streams Amazon Kinesis Data Streams Amazon MQ broker Amazon MSK stream Amazon SQS queue Apache Kafka Streams 以上のように、様々なAWSサービスからStep Functionsを呼び出すことができます。前提条件 Connectインスタンスは作成済み。電話番号も取得済み Step Functions ステートマシンを作成 AWS Step Functions ステートマシンを作成します。フローには、StartOutboundVoiceContactのみを挿入します。 [設定]タブのAPI パラメータに以下の値を記載します。[入力]や[出力]、[エラー処理]タブはデフォルトのままです。 InstanceId インスタンスID ContactFlowId コンタクトフローID SourcePhoneNumber Connectインスタンスで取得した電話番号 DestinationPhoneNumber 発信先電話番号 Attributes Connectフロー内におけるユーザーが定義するコンタクト属性インスタンスIDとコンタクフローIDは、今回アウトバウンドコールで利用するConnectフローから確認できます。Connectフローは後述します。　 APIの詳細は以下をご参照ください。 DestinationPhoneNumberとAttributesの値は、ステートマシンの実行時に渡します。 [作成]をクリックすると、自動生成されるIAMロールを確認できます。 connect:StartOutboundVoiceContactアクションを実行するには、手動でIAMポリシーを作成する必要があります。 Step Functions では、最適化された統合の IAM ポリシーを自動生成できますが、AWS […]
https://dev.classmethod.jp/articles/amazon-connect-stepfunctions-startoutboundvoicecontact/

2024-06-20 12:13:46

【Dataformワークフローをシェルスクリプトでポーリングしながら動かす】
やりたいこと Dataformワークフローを起動した後、実行状態をポーリングして完了したら次のDataformワークフローを動かすということがやりたかったです。というのも、以前作成したシェルスクリプトはどんどんDataformワークフローを起動していきますが、Dataformワークフロー実行APIは非同期APIとなり実行後は実行状態を返してくるだけで完了したかどうかは実行状態を問い合わせるAPIを打って確認しないとわかりません。一つのワークフローの実行が完了したら次のワークフローを実行する、ということを自動化したかったのでワークフローの実行状態をポーリングして、ワークフロー実行完了が返ってきたら次のワークフローを実行するというシェルスクリプトを実装しました。前日データ作成完了後に次の日のデータを作成する必要がある、というユースケースの時にこのシェルスクリプトは向いています。また、開始日、終了日を引数にしていますが配列でコンパイル変数の内容を持たせてそれを反復処理する、なんていうことにも少し手を入れれば使えると思います。処理の流れシェルスクリプト全文は以下になります。ポーリングを行なっている以下の箇所が、このシェルスクリプトの肝になるところです。この処理があるので、実行したDataformワークフローが実行完了したら、次のコンパイル結果を再びDataformワークフローを実行することができます。 Dataformワークフローを実行したレスポンスのnameパラメタを引数に以下のAPIを叩くとDataformワークフローの実行状態(state)を取得することができます。 Dataformワークフローの実行状態は以下のstateのどれかになります。今回の実装では、SUCCEEDEDだったら後続処理実行、FAILEDだったらシェルスクリプト自体を終了するようにしています。 state 概要 STATE_UNSPECIFIED 初期値。使用されることはない RUNNING ワークフローが実行中 SUCCEEDED 成功 CANCELLED キャンセル FAILED 失敗 CANCELING キャンセル中またPOLLING_INTERVAL変数でポーリング間隔を調整することができます。 Dataformの実行結果がFAILEDとSUCCEEDED以外になってしまった場合に無限ループしないようにポーリングのタイムアウト時間もTIMEOUT_LIMITで設定をしております。適宜ワークロードに則って値を調整すると良いと考えます。まとめ前回作成したシェルスクリプトはポーリング処理をしないでとにかく指定日付分Dataformワークフローを実行するというものでした。 DataformをAPIで実行する場合、前後関係がある実行をしたい場合は今回のようなポーリングをしてあげる必要があります。この記事がどなたかのお役に立てば嬉しいです。それではまた。使用しているAPI コンパイルAPI ワークフロー実行API 実行ワークフロー取得API
https://dev.classmethod.jp/articles/20240620-df18-polling/

2024-06-20 10:26:23

【[ブース紹介]可視化ダッシュボードがかっこいいレジリエンスの展示があるAWS Resilienceブースにいこう！ #AWSSummit】
こんにちは、臼田です。みなさん、AWSで持続性のあるシステム組んでますか？(挨拶今回は現在開催中のAWS Summit Japanで展示されているブースの紹介です。ブースレポート AWSの様々な展示ブースがあるAWS Villageにレジリエンス(回復力)に関する内容を扱うAWS Resilienceブースがありました。この画面を見てください。いい感じの画面が見えませんか？これですこれ！かっこいい…！この画面はGrafanaを使って、現在のAWSのヘルス状況を可視化したダッシュボードだそうですが、まずかっこいいのがいいですよね。もちろん実用性もバッチリですよね。ギリギリ左の端っこに緑のバーが少しだけ黄色くなっているところが写っていますけど、障害が発生したことがニアリアルタイムに確認できてどこで何が動いていないかなどが把握できそうです！私が気になったのはこのダッシュボードがどのように作られているのかです。Resilienceの話よりも気になりました！AWSの方にいろいろ説明していただきました。もちろんAWS Resilience Hubの話や、実際にレジリエンスが確保できているのかをテストするために利用する障害注入のサービスであるAWS FIS(最近マネジメントコンソール上でAWS Resilience Hubと統合されたんですね、知らなかったです)の話とかもしてもらいました。 AWS上で構築するサービスの可用性や回復性などが気になる方はぜひ足を運んでみてください！場所はAWS Villageの以下のところらへんです！
https://dev.classmethod.jp/articles/aws-summit-japan-2024-aws-resilience-booth/

2024-06-20 10:20:06

【オンプレミスとクラウド HPC のハイブリッド構成の優位性とは？京都大学大学院医学研究科附属ゲノム医学センター様の事例から学ぶ】
オンプレミスのスパコンを持っているにもかかわらず、なぜクラウド（AWS）で HPC 環境を構築するのでしょうか？今回は「京都大学大学院医学研究科附属ゲノム医学センター」様との事例を通してハイブリッド構成のポイントを探ります。はじめにゲノム情報を取り扱う研究機関におけるオンプレミスのスパコンと、クラウド HPC のハイブリッド構成を調査しました。公開事例をもとにハイブリッド構成を選択した理由と、構成する上で考慮点をまとめています。公開情報を元に理解を整理するために図解した構成図を載せています。正確性は担保できませんので参考程度にしてください。京都大学大学院医学研究科附属ゲノム医学センター様はハイブリッドクラウドシステムの設計についての論文を公開しています。また、AWS Summit 2023 の動画や講演資料も公開されています。これらの情報を基に、私の気になった点をまとめました。「我々のハイブリッドクラウドシステムは参考となる良いスターティングポイントを提供する」というメッセージのとおり大変参考になりました。ぜひご一読ください。 Depending on the institution and country, on-premise computing resources, supercomputing systems, public clouds, network environments, and ethical constraints must be considered in system design and implementation. Nevertheless, our hybrid cloud system provides a good starting point for reference. 引用: Design and implementation of a hybrid cloud system for large-scale human genomic research | Human Genome Variation 事例概要忙しい方向けに、1 行で課題と導入効果を説明します。オンプレミス HPC 環境の課題ヒトゲノム情報解析において超高速な解析が求められる一方で、オンプレミス HPC 環境では実行時間やメモリの制約の問題や、混雑時にはジョブがすぐに実行できないという課題があった。ハイブリッドクラウド導入の効果クラウド HPC 環境を導入し、クラウドへ拡張することでオンプレミス環境の制約を補完し、解析の柔軟性とスケーラビリティを向上させた。ハイブリッドクラウド構成ハイブリッドクラウド構成を図に書き起こしました。ジョブスケジューラはスパコンのメーカー依存で統一されていません。ジョブをサブミットする際の手順に多少違いはありますが、解析ソフトの実行環境は Singularity v3（現在の名前は Apptainer）で統一されています。吹き出しの説明ジョブスケジューラコンテナファイルシステム（ストレージ） Icons made by Freepik from www.flaticon.com ハイブリッドクラウドにAWS を選定した理由主に運用実績を重要視したようです。あとは AWS プロフェッショナルサービスを利用しているため、中期的なプロジェクトかつ、予算が比較的に潤沢にあったことが推察されます。画像引用: ヒトゲノム情報統合解析に向けた京都大学ゲノム医学センターのハイブリッドクラウドシステム構築について […]
https://dev.classmethod.jp/articles/why-choose-hybrid-hpc-lessons-from-kyoto-university/

2024-06-20 08:16:56

【Pythonで文字列の一致率を計算してみた】
はじめにある日、文字列の類似性って取れるのかなって疑問に思いました。ちょっと調べてみると、2つの方法を見つけたので遊んでみて違いなどまとめようと思います。アルゴリズム今回見つけた方法が、 difflib.SequenceMatcher.ratio() Levenshtein.distance() の2つでした。どうやらこれらは計算のアルゴリズムやそもそも測っているものが違うようです。 Gestalt pattern matching difflib.SequenceMatcher.ratio()で使われているアルゴリズムです。ぱっと見読めないんですが、ゲシュタルトと読むっぽいです。崩壊しがちなやつですね。アルゴリズムの内容としては、各部分文字列の文字列長の総和に2をかけたものを2つの文字列の和で割ることで求めるっぽいです。例えば、s1 = classmethod, s2 = classroom とすると、部分文字列の文字列長の和の2倍: 2×(|class| + |o|) = 2×(5 + 1) = 12 文字列長の和: |classmethod| + |classroom| = 11 + 9 = 20 割り算: 12 / 20 = 3 / 5 = 0.6 となります。実際に実行したら結果が0.6となったので一致しています。 Levenshtein distance Levenshtein.distance()で使われているアルゴリズムです。アルゴリズムの内容は至ってシンプルで、文字列Aと文字列Bがあるときに、文字列Aを文字列Bに置換するのに必要な操作回数(コスト)を算出します。このコストの文字列長による商が、2つの文字列の距離（差）となります。一致率を取る場合は1-距離　というようにするとよさそうです。これも、例としてs1 = classmethod, s2 = classroomとすると、 mをrに置き換え: classrethod eをoに置き換え: classrothod tを削除: classrohod hを削除: classrood dをmに置き換え: classroom となり、コストは5であることがわかります。これを長い方の文字列長: 11で割って、0.455になります。実際に計算すると一致しました。コード Gestalt pattern matching Levenshtein distance パフォーマンスどうやらGestalt pattern matchingは計算量がO(n^2)ほどになるらしいです。文字列長を少しずつ変えて確認してみます。全然違いました。使う上で決定的な違いになりそうです。ただし、「標準パッケージ」というのはかなり大きなメリットではあります。　文字列長が短いときはGestalt pattern matchingを使う、みたいな棲み分けはできてそうですね。最後にこれらのアルゴリズムはDNAの一致率を計算するのにも使われていたりするらしいです。
https://dev.classmethod.jp/articles/calc-python-string-distance/

2024-06-18 13:16:26

【Google CloudのCloud Shellをエフェメラルモードで起動してみる】
エフェメラルモードとは 5GBの永続ディスクストレージがない状態でCloud Shellのセッションが起動されます。つまりは使い捨て・一時的セッションのようなイメージです(ephemeral=一時的、短命の)。通常のCloud Shellセッションは$HOME配下に5GBまでデータを保存することができ、セッションを終了しても$HOME配下のデータは次にセッションを開いた時には保存されたままです。とはいえ永遠に保存されたままではなく、自分で削除・またはCloud Shellに120日間アクセスしていない場合は自動で削除されます。警告: $HOME ディレクトリを削除する場合、または Cloud Shell に 120 日間アクセスしていない場合は、Cloud Shell によって $HOME ディレクトリが自動的に削除され、ファイルを復元できなくなります。これが発生する前に、メール通知が届きます。Cloud Shell セッションを開始すると、$HOME ディレクトリの永続ストレージがリサイクルされるのを防止できます。 ※引用：https://cloud.google.com/shell/docs/how-cloud-shell-works?hl=ja#persistent_disk_storage エフェメラルモードでの起動の場合、ストレージはありませんが起動時間は通常モードよりも短くなります(体感でもわかるくらい早いです)。どうやって使うの？ Google Cloudにログインした状態で以下のURLにアクセスをします。 https://shell.cloud.google.com/?ephemeral=true エフェメラルモードを選択するには、https://shell.cloud.google.com URL に ephemeral=true を追加します。例: https://shell.cloud.google.com/?ephemeral=true ※引用：https://cloud.google.com/shell/docs/using-cloud-shell?hl=ja#choose_ephemeral_mode エフェメラルモードでの起動に成功するとCloud Shellの横にエフェメラルと表示されるようになります(なんかかっこよくて好きです笑)。私が初めてエフェメラルモードを使った時は、Cloud Shellの起動に失敗して以下のメッセージが出た時でした。上記のエフェメラルモードを有効にするをクリックすることでも、エフェメラルモードで起動することができました。まとめモードの違いを簡潔にまとめてみました。通常モードエフェメラルモードストレージ 5GB なし起動時間通常短くなるユースケース $HOME配下にファイル保存したい時。再実行するシェルスクリプトを実行したい時など再現性のある作業をする時。 gcloudコマンドをサクッと使いたい時。再現性のない作業をする時。この記事がどなたかのお役に立てば嬉しいです。それではまた。参考 Cloud Shellの仕組み
https://dev.classmethod.jp/articles/20240618-cloudshell-ep/

2024-06-18 13:13:16

【「AWS構成図からCloudFormationとパラメータシートを自動生成するシステムを作ってみた」という内容で登壇しました #jawsug_aiml #jawsug】
こんにちは、つくぼし(tsukuboshi0755)です！ 2024/6/18に開催されたBedrock Claude Night 2（JAWS-UG AI/ML支部 × 東京支部コラボ）にて、「AWS構成図からCloudFormationとパラメータシートを自動生成するシステムを作ってみた」というタイトルでLT登壇しました。 JAWS-UG AI/ML支部とは？ Japan Amazon Web Servicesにおける、AI及びMLを専門としたユーザグループです。こちらでは、AWSのAIやMLに特化した様々なテーマのLTを視聴する事が可能です。 LT資料補足今回のシステムを構築するリポジトリは以下になります。 SAM CLIとBedrockモデルが利用できるAWSアカウントであれば誰でもデプロイ可能なので、ぜひ試してみてください！最後に今回は「AWS構成図からCloudFormationとパラメータシートを自動生成するシステムを作ってみた」というタイトルでLT登壇しました。今回の登壇を通じて、生成AIを使ってどこまでクラウドエンジニアの仕事を自動化できるのか、これからも時間があれば追求してみたいなと思いました。以上、つくぼし(tsukuboshi0755)でした！
https://dev.classmethod.jp/articles/jaws-ug-aiml-bedrock-claude-night-2-lt/

2024-06-18 11:16:24

【画像の回転などの変換処理が埋め込みベクトルに与える影響を確認してみた】
こんちには。データアナリティクス事業本部機械学習チームの中村(nokomoro3)です。今回は小ネタですが、画像の反転や位置の違いが埋め込みベクトルにどの程度影響を与えるのか知りたかったので、本記事で試してみたいと思います。使用する画像ネコの画像をいらすとやから拝借しました。こちらに対して、以下のような変換を加えてみます。サイズ変更回転位置替えモノクロ化そしてネコ以外の画像も比較のため、以下のイヌの画像も使ってみます。これらの画像データを Titan Multimodal Embeddings で埋め込みベクトルに変換して、コサイン類似度を比較してみようと思います。埋め込みモデルについて使用する埋め込みモデルは以下を用います。 Amazon Titan Multimodal Embeddings G1 model - Amazon Bedrock こちらはテキストおよび画像ファイルを入力として扱い、デフォルトで1024次元の埋め込みベクトルを出力します。今回はPython（Boto3）で埋め込みベクトルに変換します、以下のブログからコードをお借りしました。 [Amazon Bedrock] Amazon Titan Multimodal Embeddings G1モデルを使用して、「きのこの山」と「たけのこの里」の分類モデルを作成してみました | DevelopersIO 埋め込みベクトルを作成する関数は以下となります。 def get_embedding(bedrock, image_path: str, dimensions: int = 1024) -> List[float]: with open(image_path, "rb") as image: body = image.read() response = bedrock.invoke_model( body=json.dumps( { "inputImage": base64.b64encode(body).decode("utf8"), "embeddingConfig": {"outputEmbeddingLength": dimensions}, } ), modelId="amazon.titan-embed-image-v1", accept="application/json", contentType="application/json", ) response_body = json.loads(response.get("body").read()) return response_body.get("embedding") 作成した埋め込みベクトルを使って、コサイン類似度を計算し、画像間の類似性を確認してみたいと思います。結果まずは結果からお示しします。類似度が高い順に棒グラフにしてみました。イヌとネコのコサイン類似度が一つ基準となり 0.710 程度となっています。ですので今回の実験に限って言いますと、0.710 程の違いがでると違う画像になっているという風に認識しても良さそうです。それよりも差が出たものとしては、白色ノイズが強めにかかっている場合は 0.677 程度になることもありました。ネコ自体の数が増えているケースも類似度が 0.836 程度には下がり、 90°などの回転処理もそれに近いくらいの 0.850 までは類似度が下がっているようです。またモノクロ化は意外と差異がなく 0.879 程度となっています。この辺りは今後の処理の参考になりそうです。また変換のカテゴリごとの値は以下の表をご確認ください。(グラフと同様の値ですが、カテゴリ分けしています) 類似度ファイル名 1.000 ネコ.png 0.710 イヌ.png 0.869 ネコ_背景=緑.png […]
https://dev.classmethod.jp/articles/image-embedding-with-image-edit-2/

2024-06-18 11:13:16

【[アップデート] Amazon Cognito のトークン生成前 Lambda トリガーのトリガーイベントバージョン V2 が使えるようになっていたので試してみた】
いわさです。 Amazon Cognito では認証実行後に ID トークンとアクセストークンを取得することが出来ます。このトークンクレームをカスタマイズしたいことがあるのですが、ID トークンについては以前からクレームの上書き・追加・抑制を行うことが出来ていました。実は最近（2023 年 12 月と 2024 年 5 月）になってこれらのトークンカスタマイズ機能でより高度なカスタマイズが行えるようになっています。具体的には 2023 年 12 月には、従来の ID トークンのみだけでなくアクセストークンもカスタマイズ出来るようになっています。そして 2024 年 5 月にはより複雑なデータ形式を設定することも出来るようになりました。公式ドキュメントやマネジメントコンソール上では従来のカスタマイズを V1 あるいは基本、高度なカスタマイズを V2 なんて呼ばれていたりします。高度なカスタマイズいいじゃないかとなりそうですが、一点前提条件があってこれらのトークンカスタマイズ機能 V2 を使うためには対象のユーザープールでアドバンスドセキュリティ機能を有効化する必要があります。アドバンスドセキュリティを有効化すると Cognito ユーザー単価が変わるのでそこだけ注意が必要になっています。今回私のほうでこれらのアップデートを試す機会がありまして、従来の V1 と V2 の違いを比較しながら簡単に検証してみましたので紹介したいと思います。まずは普通に認証してトークンを取得してみるまずは、特に Lambda トリガーを設定せずにトークンを取得してみます。前提としてユーザプールにユーザーを作成し、初期パスワードから更新済みの状態でサインインに成功する状態です。 ID トークンが取得出来ていますね。 jwt.io などでトークン検証を行いつつペイロード部分だけ抜きだしてみます。なるほど。これがデフォルトの ID トークンですね。基本機能を使って ID トークンをカスタマイズしてみる冒頭の北野さんの記事、あるいは次の公式ドキュメントを参考に、Lambda トリガーで使う関数を用意して、ユーザープールの Lambda トリガーを有効化してみましょう。関数は公式ドキュメントと同様に次のような感じで実装しました。 claimOverrideDetailsで上書きするクレームと抑制するクレームを指定する感じですね。で、これをユーザープールのトークン生成前 Lambda トリガーとして設定します。非活性になってますがトリガーイベントバージョンに「基本機能 + アクセストークンのカスタマイズ」という選択肢があることがわかりますね。これは後で試すやつです。上記 Lambda トリガーを設定した状態で再びinitiate-authコマンドでトークンを取得してみます。おぉなるほど。 my_first_attributeとmy_second_attributeが追加され、emailが出力されなくなりましたね。 Lambda トリガーによって期待どおりにカスタマイズされています。文字列のみ設定できるアップデートアナウンスを見てみると、今回の V2 では文字列だけではなくブール値や数値も設定出来るようになっているようです。ということは V1 ではブールや文字列は設定出来ないということか。試してみましょう。実行してみます。なるほど。カスタマイズは出来ていますが、ブール値や数値を指定した部分が文字列として設定されていますね。 V2 (基本機能 + アクセストークンのカスタマイズ) を使ってみるでは続いて V2 を使ってみましょう。まずは Lambda トリガーの設定をバージョンアップしたいのですが、前提として Cognito アドバンスドセキュリティ機能を有効化する必要があるのでそちらを先に有効化しておきましょう。そうすると Lambda トリガーで「基本機能 + アクセストークンのカスタマイズ」が選択出来るようになりました。 Lambda トリガーの編集からトリガーイベントバージョンを更新します。現在使われているトリガーイベントバージョンは以下からも確認が可能ですね。さて、Lambda […]
https://dev.classmethod.jp/articles/cognito-user-pools-customize-access-tokens/

2024-06-18 09:16:26

【【実践】Google Colab Enterprise ノートブック単位でアクセスを制御する方法を解説】
概要 Google Colab Enterpriseとは、企業でGoogle Colabを利用したい時に活用できるセキュリティや統合性を重視したエディタープラットフォームになります。統合性とは、Google Cloudのサービスとシームレスに連携できるため、開発がよりスピーディかつ楽に行えます。また、今回ご紹介する「ノートブック単位でアクセスを制御する」場合、IAMロールを使用したセキュリティガバナンス向上に寄与します。通常のWebから使用できるGoogle Colabでは、IAMを使用したユーザーのアクセス制御の概念自体が無いため、この辺りが企業での運用を意識した構成なっています。細かな基礎的な解説は前回ブログにしているので、ご覧ください。 IAMロール実際に触る前にGoogle CloudとしてのIAMについて簡単に解説します。まず、先もお伝えした通り、通常のGoogle Colabとの違いはセキュリティ機能や統合性と説明しました。それはGoogle Cloud内部で実行されるのが今回のColab Enterpriseだからです。それにより、Google Cloud内のセキュリティ機能と連携することができ、当然IAM制御も可能となります。そして、このIAM制御とは、Google Cloud内に存在するプリンシパル(ユーザーやサービスアカウント）に対してロール（権限）を割り当てることで、そのリソースへのアクセス自体を許可するといったものです。以下のブログでも、IAMロールについて整理しているのでご覧ください。ノートブック単位でアクセスを制御ここからは実際にGoogle Cloud コンソールを操作して、IAMでのアクセス制御を行います。 Google Cloud コンソールの検索窓に[Colab Enterprise]と入力し、Vertex AIサービスの画面へ移動します。各ノートブックの左端にある赤枠を押下します。小さなポップアップが開いたら[共有]をクリックします。赤枠の[ADD/USER Group]を押下します。追加する[IAMユーザー]を入力し、[ロール]を３種類から選択します。 1つ前の画面に戻り、ユーザーが追加されているか確認してください。では、先ほど追加したユーザーでこのプロジェクトのデモノートブックを開いてみましょう。先ほどノートブック左端を押下し[共有]を選択しましたが、今回は[リンクを取得]をクリックします。取得したリンクを追加したIAMユーザーのChromeで開きますが、下記のようにエラーが出てしまいました。プロジェクト自体に権限が必要なため、コンソールに戻ります。コンソールの検索窓から[IAMと管理]を入力して移動し、[アクセス権を付与]をクリックします。（Dataform閲覧者ロールを付与）もう一度付与したユーザーのChromeでコンソールのデモノートブックを開いてみましょう。無事デモノートブックが表示されました。ただし、閲覧者の権限のためノートブックの編集などはできません。今回のようにプロジェクトで必要な権限とそのリソースで必要な権限が分かれている場合が多いので、IAM権限のエラー解決が必要な際には覚えておくことはおすすめします。まとめ今回はGoogle Colab Enterpriseのノートブック単位でのアクセス制御について解説しました。 Colab EnterpriseはGoogle Cloudの一部であるため、その他のGoogle Cloudサービスの仕組みを理解することが求められます。しかし、クラウド環境を運用する際にはセキュリティやガバナンスの遵守が不可欠なため、中央集中的にPythonコードの環境を統一したい場合には非常に便利です。ぜひ、Google Cloudでの運用を検討してみてください。
https://dev.classmethod.jp/articles/google-colab-enterprise-notebook-access-control/

2024-06-18 09:13:16

【クラスメソッドメンバーズのバックエンドAPIをリプレイスしました】
AWS事業本部サービス開発室の佐藤です。クラスメソッドメンバーズポータルのバックエンドAPIの開発を担当しています。はじめに弊社ではクラスメソッドメンバーズ（以下メンバーズ）と呼ばれるAWSの利用費割引や請求代行、コンサルティング、セキュリティ、24/365サポートなどAWSに関することをおまかせしていただけるサービスを提供しています。その中でメンバーズに契約いただいたお客様に対して、クラスメソッドメンバーズポータル（以下CMP）というクラスメソッドサポートへの問い合わせやAWSアカウントリソースの利用状況を可視化できるWebサービスを提供しています。今回、CMPで利用しているバックエンドAPIをリプレイスしたのでその背景とリプレイス方法について簡単に紹介したいと思います。リプレイスの背景 CMPは契約しているお客様向けに2013年頃から提供しているWebサービスで、バックエンドはSpring Boot + Javaで実装されています。歴史の長いサービスのためSpring Bootのフレームワークのバージョンや各種利用しているライブラリが古く継続的なアップデートができない状態になっていました。他にもCMPのフロントエンドの刷新が予定されていて、バックエンドも大幅なコード変更が必要ということも背景にありました。既存のSpring Boot + Javaの資産をなるべく流用したかったため、リプレイス先はサーバーサイドKotlin（Spring Boot）に決まりました。環境旧API ライブラリバージョン Java 11 Spring Boot 2.1.9 Gradle 6.9.2 新API ライブラリバージョン Kotlin 1.9.23 Spring Boot 3.1.11 Gradle 7.6 リプレイスの方針リプレイスには以下の2つの方針がありました。既存のJavaコードを徐々にKotlinに移行しつつライブラリやフレームワークのバージョンを上げていく新規でKotlinのプロジェクトを作成し、既存のJavaコードを移行していく今回のリプレイスでは後者を選択しました。ちょうどSpring Boot 3系のGAがアナウンスされていてSpring Boot 2系からの移行が大変そうなこと、新旧APIで並行稼働しつつ段階的に移行していく必要があるなど、既存のコードベースを修正するのではなく、新規で作成しライブラリやフレームワークも最新にしつつ実装していく方針にしました。リプレイスの方法新規Kotlinプロジェクトの作成リプレイスするにあたって、まずは Spring Initializr を利用しSpring Boot 3系 + Kotlinの雛形を作成しました。必要なライブラリやバージョンを画面ポチポチで作成できるので便利です。Projectは Gradle - Kotlin、Languageは Kotlin、Spring Bootは当時最新だった３.１.２を選択して作成しました。作成したらzipファイルがダウンロードできるのでローカルで展開して準備完了です。既存のJavaプロジェクトから必要なファイルをコピー新規でプロジェクトを作成したら、既存のコードから必要なJavaファイルをコピーしていきました。基本的にはController, Request, Response, Service, DTO, Entity, Repository, ConfigなどのSpringの主要なコンポーネントをコピーしました。この段階で必要なさそうなJavaのファイルなどを棚卸しています。 JavaからKotlinへの変換次にKotlinへの変換を行いました。変換についてはInteliJ IDEAの JavaからKotlinへの変換機能というのがあり、基本的にはこちらを利用して変換作業を行いました。Javaのファイルを右クリックして Convert Java File to Kotlin File を選択するだけで全て自動的に変換してくれます。例えば、以下のようなLombokを利用したJavaのEntityクラスの場合 Kotlinのデータ変換機能を利用すると以下のようなコードに変換してくれます。ただ、このままだとLombokのアノテーションが付与されているので冗長です。また、すべてNullableなプロパティに変換されてしまうという問題もあります。Kotlinの場合はdata classがあるので、それを利用する形に修正します。すると以下のようになります。 JavaだとアノテーションまみれだったのがKotlinだとdata classを利用することでスッキリ書くことができました。他にも、Kotlinは基本的にJavaの機能がそのままつかえるので、JavaのStream APIやgetterなどはそのまま変換されます。このままでも問題なく動作するんですが、せっかくKotlinを利用しているのでKotlinの書き方にしたいですよね。Kotlinだと以下のように書けます。 JavaのOptionalを利用している場合も注意が必要です。OptionalがあるJavaコードをそのまま変換すると以下のように変換されます。 KotlinはOptionalを利用しなくてもNull安全に書けるので上記のコードは以下のように変換します。 JavaのOptionalからKotlinのNull安全機能の変換については以下の記事が参考になります。 https://typealias.com/guides/java-optionals-and-kotlin-nulls/ 大まかな変換についてはInteliJの機能におまかせして細かな部分を適宜修正する形で変換を行っていきました。他にもこの時点で不要なコードなども極力削除しました。このようにInteliJの変換機能を使いつつ移行作業を行っていった結果、JavaのコードをすべてKotlinに変換する事ができました。また、全体のコード行数も30%程度削減できました。今後は、Javaの旧APIとKotlinの新APIを並行稼働しつつ徐々に新APIに移行していく予定です。まとめクラスメソッドメンバーズのバックエンドAPIのリプレイスについて簡単ですが紹介させていただきました。KotlinはJetBrainsが開発していることもあり、Kotlinに関するInteliJの機能が充実していて、InteliJのおかげでかなり楽をして移行ができたんじゃないかなと思います。また新規プロジェクトベースでリプレイスを進めたので、既存のAPIの影響を考えなくてよくドラスティックに修正を行えました。他にもSpring Boot 3系をベースに実装したので2系から3系へのマイグレーションを特に意識せずに行えたことも大きかったとおもいます。今回のリプレイスでテスト環境の整備もすることができましたが、それについてはまた別の記事で紹介したいなと思っています。
https://dev.classmethod.jp/articles/classmethod-members-backend-replace/

2024-06-18 08:22:46

【セルフマネージドActive Directoryと信頼関係にあるAWS Managed Microsoft ADのユーザーを使ってAmazon FSx for NetApp ONTAPにSMBで接続してみた】
異なるドメインに参加しているファイルサーバーにアクセスしたいなこんにちは、のんピ(@non____97)です。皆さんは異なるドメインに参加しているファイルサーバーにアクセスしたいなと思ったことはありますか? 私はあります。特に起こりうるシチェーションとしてはAmazon Workspaces(以降Workspaces)を使用している場合です。WorkspacesはManaged Microsoft AD(Managed MSAD)に参加させ、ファイルサーバーはオンプレミスやVPC上にあるセルフマネージドADに属しているという場面はよくあるかと思います。異なるドメインに参加しているファイルサーバーにアクセスする場合は、ドメイン間で信頼関係を組んであげる必要があります。信頼関係の仕組みは以下Microsoft公式ドキュメントをご覧ください。また、その場合どのようにしてグループアカウントの運用を行い、どのようにしてアクセス許可をすれば良いのかも気になるかと思います。試しにAmazon FSx for NetApp ONTAP(FSxN)をセルフマネージドADに参加させ、セルフマネージドADと信頼関係にあるAWS Managed Microsoft ADのユーザーを使ってFSxNにSMBで接続をします。いきなりまとめセルフマネージドActive Directoryと信頼関係にあるAWS Managed Microsoft ADのユーザーを使ってFSxNにSMBで接続することは可能 FSxNのSMBサーバーが属しているドメインと異なるドメインのユーザーからのアクセスを許可したい場合は、SMBサーバーのドメインからアクセス許可したいドメインユーザーのドメインへの片方向の信頼関係を作成するマルチプロトコルアクセスの場合は双方向の信頼関係を組む必要があるドメインユーザーをグローバルセキュリティグループやドメインローカルグループに所属させた場合、一度サインアウトされるまで所属しているグループに対するアクセス権限はドメインユーザーに反映されないやってみた検証環境検証環境は以下のとおりです。今回はcorp.non-97.netとnon-97.privateという2つのシングルフォレスト・シングルドメインの間で信頼関係(フォレストの信頼)を行います。なお、外部の信頼でも問題ないようです。企業ドメインは信頼されたドメインのロールを担い、AWS Directory Service マネージドドメインは信頼するドメインのロールを担います。検証済み認証リクエストは、ドメイン間を一方向にしか移動しません。これにより、企業ドメインのアカウントがマネージドドメインで共有されているリソースに対して認証を行うことができます。この場合、Amazon FSx はマネージドドメインとのみ対話します。マネージドドメインは、認証リクエストを企業ドメインに渡します。注記信頼されたドメインに対して Amazon FSx で外部の信頼タイプを使用することもできます。チュートリアル 1:スタートするための前提条件 - Amazon FSx for Windows File Server 今回はセルフマネージドADからManaged MSADへの一方向の信頼関係を組みます。マルチプロトコルアクセスを実現するためにUNIXユーザーをドメインユーザーにマッピングする際は双方向で信頼関係を組む必要があるようです。原因 ONTAPは最初にUNIXユーザを認証し、次にS4U2Selfを使用してWindowsクレデンシャルを構築します（トークングループへのフォールバック）。 Kerberos制約委任では、ドメインAのサーバ（サービス）が、ドメインBのユーザの認可情報を要求している場合、双方向の信頼が必要なユーザの代わりにサービスチケットを取得できる必要があります。 RFE 1052237-NFSマウントが混在/ NTFSセキュリティ形式のボリューム/ qtreeを使用していて、環境に一方向の信頼がある場合に中断される解決策この問題を解決するには、双方向の信頼が必要です。双方向の信頼によるエクスポージャーを制限するには、選択認証を使用して、CIFSサーバコンピュータオブジェクトなどの特定のオブジェクトのみが信頼を通過できないようにします。ファイル所有権の設定ワークフローの一環として、ONTAPはユーザ（所有者として設定）のWindowsグループメンバーシップを取得してユーザクレデンシャルを作成します。これにより、SVMは S4U2selfを使用してユーザのクレデンシャルを取得できます。これは匿名のSAMRパイプを使用した場合に比べて正確であるだけでなく、より安全な方法でもあります。 ONTAP は、一方向の信頼を介して、信頼できるドメインからWindowsユーザにUNIXユーザをマッピングすることができません - NetApp シングルフォレスト・シングルドメインの場合はAGDLP、マルチフォレストの場合はAGUDLPが推奨とされているようです。アルファベットのそれぞれの意味は以下のとおりです。 A : Account (アカウント) G : Global Group (グローバルグループ) DL : Domain Local Group (ドメインローカルグループ) U : Universal Group (ユニバーサルグループ) P : Permission (権限) 急にユニバーサルグループやグローバルグループ、ドメインローカルグループと出てきましたが、こちらフォレストやドメインのリソースのグルーピングをする際に使用します。詳細は以下Microsoft公式ドキュメントをご覧ください。ざっくりとした使い分けは以下で良いと思います。ユニバーサルグループ: フォレスト内の複数のドメイン内のユーザーをグルーピングする場合グローバルグループ: 単一ドメイン内のユーザーをグルーピングする場合ドメインローカルグループ: […]
https://dev.classmethod.jp/articles/self-managed-active-directory-trust-relationship-aws-managed-microsoft-ad-amazon-fsx-netapp-ontap-smb-connection/

2024-06-18 08:19:36

【[オフライン世界最速？AWS re:Inforce 2024 re:Cap セミナー] 『「ナンモワカラン」から「チョットワカル」へ！ Private CA Connector for SCEPについて話します』というタイトルで登壇しました。#AWSreInforce】
こんにちは！ AWS 事業本部コンサルティング部のトクヤマシュンです。【オフライン世界最速？】AWS re:Inforce 2024 re:Cap セミナーにて、『「ナンモワカラン」から「チョットワカル」へ！ Private CA Connector for SCEPについて話します』というタイトルで登壇しました。先日のAWS re:Inforce 2024のキーノートで発表されたこちらのアップデートの内容をテーマにしています。登壇資料今回の登壇のポイントキーノートを聞いていて、「なに？SCEP？ナンモワカラン...」となっていたので、改めてどのようなアップデートだったのか、調べてみました！私のような「ナンモワカラン」状態の人が読んでも「チョットワカル」になってもらえることを目指しましたので、ぜひご一読いただけますと嬉しいです！参考リンク CURRY HOUSE Babbulkund Instagramアカウント (P.2) CURRY HOUSE Babbulkund Twitterアカウント (P.2) [速報] AWS Private CAでConnector for SCEPが利用できるようになりました（Preview）#AWSreInforce (P.5) How Connector for SCEP works(P.15-16) 最後に以上、AWS re:Inforce 2024のキーノートで発表された AWS Private CA Connector for SCEP についての登壇ブログでした。「ナニモワカラン」の方は「チョットワカル」になっていただけますと幸いです。今回初めての日比谷オフィス登壇だったのですが、とても楽しかったです。企画してくれたあしざわさん、たかくにさん、そして参加いただきました皆様、本当にありがとうございました。
https://dev.classmethod.jp/articles/aws-reinforce-2024-recap-seminar-private-ca-conector-for-scep/

2024-06-18 08:16:26

【[アップデート]Amazon Data Firehoseが認証情報をAWS Secrets Managerより取得できるようになりました】
初めに先日Amazon Data FirehoseとAWS Secrets Manager統合のリリースがありました。これまでAmazon Data FirehoseではNew RelicのAPIキー等認証情報を入力するサービスを利用する際その値をFirehose側で直接指定する形となっておりました。 CloudFormation等を利用して構築する際は動的参照を利用することでSecrets Managerの値を参照してデプロイ時に差し替え、Secrets Manager側からのローテーション時のLambda関数処理による差し替えといったことは可能でしたがあくまで外側の仕組みとしてFirehose側の設定値を書き換えるものとなっておりました。 (シークレットの値の変更＋αのαの部分がうまくやればできたけど機能としてのサポートではなかった) 今回のアップデートで認証情報の値直接ではなくシークレットのARNを指定できるようになりFirehose側が必要に応じてSecrets Managerより値を取得するようになったため、＋αの処理なくシークレットの値の変更のみで対応できるようになり秘密情報のローテーションをよりシンプルに実現することができるようになります。またシークレットの値を直接取り扱わないため設定の変更処理をより安全に実現することも可能となります。試してみる今回はCloudFormationを利用して設定してみます。今回はHTTPエンドポイントを利用しますがSecretsManagerConfigrationというパラメータが追加されておりこちらに対して有無効、シークレットのARN、取得に利用するIAMロールの指定をすればよさそうです。またこの値は従来のアクセスキーの指定同様、リクエスト上のX-Amz-Firehose-Access-Keyヘッダに反映されます。どのヘッダに利用されるか等は送信先のサービスにより異なるため各種サービスの設定値のドキュメントをご参照ください。実装以下のテンプレートで環境を構築します。シークレットに指定すべき値についてはサービスにより異なりますので利用するサービスに合わせて設定しましょう。今回HTTPエンドポイントの場合はapi_keyがキーとなるJSON値を設定します。今回は以下のような値となっております。 HTTPエンドポイントの先ではX-Amz-Firehose-Access-Keyヘッダの値をログに出力するようにしておきます。通信はPOSTで来るため受信側でメソッドの判定がある場合は注意しましょう。動作確認ストリームにデータを設置するとシークレット上のapi_keyの値が出力されていることが確認できます。 Firehose側に変更が入らないように個別にシークレットの値を送信して再度データし変更されていることを確認します。 https://docs.aws.amazon.com/ja_jp/firehose/latest/dev/using-secrets-manager.html Firehose caches the secrets with an encryption and uses them for every connection to destinations. It refreshes the cache every 10 minutes to ensure that the latest credentials are used. なおFirehoseではシークレットの値を約10分程度キャッシュするため切り替えタイミングと配信タイミング次第で意図せず旧値が混ざってしまう可能性があります。実際に04:44(UTC)ごろに変更を行いデータの送信を行いましたが04:58頃もキャッシュが残っているためか一発目は古いシークレットが利用されており、その直後から値が切り替わっていることが確認できました。キャッシュ時間や削除については画面を見る限りでも本日入れたAWS CLIのv1側でもそれっぽい機能は見当たらないためこの辺りの制御は現状できなさそうです。終わりにシークレットの値を直接参照してくれるようになったことで、必要以上に秘密情報を外側で取り合わずより安全にシンプルに対応できるものとなるアップデートでした。 Firehose側で直接値を持つわけではなくSecrets Manager側を動的に参照するためがシークレット参照による料金発生がある点は注意しましょう。 10分程度キャッシュは行われるため毎回というほどではありませんが、逆にキャッシュしてしまう関係で変更反映にラグができてしまうため送信先で認証情報が一つしか持てない場合は一時的に送信に失敗してしまう可能性があります。現状この辺りのコントロールができるわけではなさそうなのでローテーションが必要でも場合により別の方法でローテーションした値を直接Firehose側に持たせた方が良い場合もありそうです。あくまで選択肢が一つ増えたほどで見たいただくのが良いのではないかなと個人的には考えております。
https://dev.classmethod.jp/articles/data-firehose-support-secrets-manager-integration/

2024-06-18 08:13:16

【株式会社Momentor 代表取締役坂井風太氏も登壇！Classmethod ODYSSEY ONLINE(HR)のセッション見どころ紹介 #cm_odyssey】
2024年07月に開催されるクラスメソッド設立20周年イベント『Classmethod ODYSSEY』。約1ヶ月間のイベント期間中、日本各地で行われるオフラインイベント、また多種多彩なテーマでお送りするオンラインイベントで合計200以上のセッション、クラスメソッド社外の登壇者数も50人以上と非常に豪華なラインナップとなっています。当エントリでは、この『Classmethod ODYSSEY』のイベントの中でHR(Human Resources：人的資源全般に関係する業務)に関するセッションの概要と『セッションの見どころ』について紹介したいと思います。お申し込みはこちら目次 Classmethod ODYSSEYにおけるHR関連のセッション一覧と見どころ紹介 2024/07/10(水) 開催の『Classmethod ODYSSEY ONLINE(HR)』トラックについて 17:10 - 17:50 / 問題を明確にする方法(田部井勝彦) 18:00 - 18:40 / ブームだけで終わらせない、組織内でコーチングを活用する方法(横内優子) 18:50 - 19:30 / セルフマネジメントやピープルマネジメントにも使える「自己効力感の高め方」(徳山幸美) 19:40 - 20:20 / 組織はなぜ衰退するのか　〜自社愛が招く悲劇性について〜(坂井風太) まとめ　 Classmethod ODYSSEYにおけるHR関連のセッション一覧と見どころ紹介 HR関連のセッションはオンラインイベントである『Classmethod ODYSSEY ONLINE(HR)』トラックで開催されます。開催日時は2024/07/10(水) 17:00 - 20:30、Zoomにて開催予定。です。 Classmethod Odyssey クラスメソッド設立20周年テックイベントオンライン日程セッション紹介セッションの見どころ紹介については、クラスメソッド株式会社人材育成室所属の豊崎隆さんにミニインタビュー形式でコメントを頂きました。アウトプット文化による第一想起を育てる - Speaker Deck キャリアと組織の成長塾#1 アスリートからエンジニアの道へ - Speaker Deck 　 2024/07/10(水) 開催の『Classmethod ODYSSEY ONLINE(HR)』トラックについてーーー：ということで豊崎さん、よろしくお願いします。豊崎：よろしくお願いします。ーーー：まず初めに、2024年07月10日開催のHRトラック、このセッションの並びについてはどうでしょうか？クラスメソッドのメンバーが3人、そして最後に社外からの登壇者としてスペシャルゲスト：坂井風太さんという並びになっていますが。豊崎：坂井さんはDeNAの元人事でもいらっしゃった方なので、『クラスメソッドの人事』と『DeNAの元人事』のお話が聞けるという点では面白い形になったかなという感覚があります。そしてこれを楽しむには、クラスメソッドの人事の体制も知っててもらえると、より面白く見えるんじゃないかと。クラメソ3人のセッションでは『クラスメソッドの人事は今こういう感じになっています』という部分を知って頂けると思います。ーーー：クラメソメンバー3人が所属するチームや組織はどういうことをやっているんですか？豊崎：横内さんの所属する人事労務室については採用と労務を取り扱っています。徳山さんの所属する人事労務室については採用と労務を取り扱っています。横内さんと僕の所属する人材育成室は全社員を対象にした育成部門です。そして田部井さんは組織開発室で、従業員エンゲージメント、つまり社員が企業理念を理解し自発的にパフォーマンスを発揮する組織に向けた取り組みを取り扱っています。それぞれの業務についての話をするわけじゃなくて、業務の中で得た知見とか経験から来る学び、みたいなものを話すのが前半の3つのパートで、その後に発表頂く坂井風太さんは、組織論みたいな話を大きくしてもらえるのでそういった対比も面白いんじゃないかなと思います。ーーー：なるほど。豊崎：クラメソ目線で、皆さんに伝えたいことが3つ並んでいるかなっていう感じです。いずれのセッションの内容も役に立つ内容を視聴者の皆さんに持って帰って頂けると思います。ーーー: 最後に控える坂井風太さんのセッションもとても楽しみですね。　 17:10 - 17:50 / 問題を明確にする方法(田部井勝彦) 登壇者クラスメソッド株式会社人事グループ組織開発室室長田部井勝彦田部井勝彦 | DevelopersIO タイトル問題を明確にする方法概要人や組織に関わる問題を解決するにあたって、まずは問題を明確にすることが必要になります。問題を曖昧に扱うケースと対比しつつ、問題を明確する利点、問題を明確にするためのテクニック、問題を明確にした事例などについて説明します。ーーー: HRトラック1発目は田部井さん。田部井さんはブログでも組織開発に関する内容をコンスタントにアウトプットされていますね。豊崎: 組織開発を行うにあたっての課題として大きなポイントは、人(人事)に関わることって、結構問題が抽象化されていると思っていて。根本の原因とかを分解しづらいことが多いんだけども、組織を改善していくにあたっては可能な限り問題を明確にしてから取り組まないと、何していいのか分からないっていう。ーーー: あぁ、言われてみれば確かに。豊崎: それでこのタイトル(問題を明確にする方法)が来るっていう。田部井さんは課題や問題に直面した初手の段階で、このメソッドを日々使っていると。そのあたりをこの登壇では話してくれるのかなぁと思っています。対処に困るような、非常に抽象度の高い問題に相対している人には、すごい役立つんじゃないかなと思います。ーーー: […]
https://dev.classmethod.jp/articles/introduce-classmethod-odyssey-online-hr_20240710/

2024-06-17 09:13:16

【dbt jinja テンプレートエンジンの基礎構文について調べてみた】
こんにちは！よしななです。今回は、dbt jinja テンプレートエンジンの基礎構文について実際に自分の手元で触って挙動を確かめたので、備忘録として残します。目次前提 jinja とは jinja の基礎構文変数の代入と参照 if 構文 for 構文まとめ参考文献前提本ブログのコードは以下の環境で実行しています。 OS Windows 11 ターミナル VSCode / PowerShell で実行本ブログのコードを実行するには、以下の準備が必要です。今回は、以下の準備がすべて完了した前提で進めます。環境セットアップ dbt-core インストール AWSS Athena と dbt-core は接続済み参考記事：https://dev.classmethod.jp/articles/get-start-dbt-core-with-athena/ dbt initコマンドを実行し、dbt モデルを格納するフォルダtest_jinjaを作成データの準備 Kaggle - Rossmann Store Sales の train.csv を使用しています Amazon Athena で train.csv をもとに以下の DDL 文を実行しています。 dbt init実行で作成したtest_jinjaプロジェクト配下に dbt モデル：test_jinja_01.sqlを作成します。 test_jinja_01.sqlに dbt モデルのロジックを書いていきます。 jinja とは jinja とは、Python で開発されたテンプレートエンジンの一種で、HTML や CSS など様々なテキストファイルの記述に用いられます。 dbtでは、SQL と Jinjaを組み合わせることができ、dbt プロジェクト内で SQL の機能を強化・拡張するためのツールとして機能します。 jinja を用いて dbt でできることについて、次項で説明します。 jinja の基礎構文 {{ ... }}：式式の結果を文字列として出力します。式を使用して変数を参照したり、dbt macros を呼び出したりすることができます。 {% ... %}：制御構文 for ループや if 文の設定、変数の設定や変更、マクロの定義など、フローの制御に使用します。 {# ... #}：コメント dbt モデルとして実行しないコメントなどを挿入する場合に使用します。変数の代入と参照 Jinja の中で変数を代入する場合は{%- set -%}を使用し、変数を参照する場合は{{ 変数名 }}を入力します。 […]
https://dev.classmethod.jp/articles/dbt-jinja/

2024-06-17 08:13:16

【AthenaのクエリでWHERE句に関数を利用してもパーティションを効率よく走査してくれるか確認してみた】
CX事業本部@大阪の岩田です。年(year)と月(month)にパーティションが切られたAthenaのテーブルに対して直近1週間のデータを集計するクエリを書く機会がありました。直近1週間ということで月跨ぎのケースを考慮して最初は以下のようにWHERE句を書いていました。しかし、WHERE句の条件が増えてくると最初にパーティションを絞り込む部分がゴチャゴチャしてくるのが気になり以下のような書き換えを検討しました。ここで1つの疑問が浮かびました。パーティションが設定されたカラムに対してCONCAT等の関数を適用した場合でもAtehanaのクエリエンジンは当該パーティションだけを効率よく走査してくれるのでしょうか？一応prestroについて調べると以下の情報がヒットしたのでAthenaでもパーティションを考慮していい感じにフィルタしてくれそうではあります。ということで実際にいくつかのクエリを実行しながら確認してみました。環境今回利用した環境です Athena engine version 3 パーティション管理: Glue Data Catalog 以前こちらのLTで利用したSlackの投稿を分析対象としてSQLを発行していきます Glueのマネコンから確認できるテーブルのパーティションは以下の通りでしたやってみるここから色々なEXPLAIN ANALYZEを付けながら色々なSQLを実行し、出力を確認していきます。とりあえず全件スキャンまずは全件スキャン時の実行計画を確認しておきます。本来は「Athena破産」のリスクがあるので避けるべきSQLですが、まあ対したデータ量じゃないことが分かっているので気にせずスキャンしちゃいます。実行結果です 21.17MBのデータをスキャンしていることが分かります。 yearとmonthを1つずつ条件指定続いて2019年12月と2020年1月のデータを対象に絞り込んでみます。この際year=...month=...といった具合に特に関数は使わず地道に１つづつ条件を指定していきます。実行結果ですスキャン対象が4.84MBに減少し、以下の出力の通りアクセス対象のパーティションが絞られていることが分かります CONCATとBETWEENで範囲を指定してみる続いてCONCATとBETWENNを使って日付=パーティションの範囲を指定してみます。実行結果です先ほどと同様スキャン対象は4.84MBでした。CONCATを使っても問題なくパーティションを有効活用できてそうですね date_parseしてみるせっかくなのでもう少し試してみます。yearとmonthをdate_parseしてvarcharからtimestamp型にCASTするとどうでしょうか？実行結果ですこちらも問題なくパーティションを有効活用できています。 RANDOM()と組み合わせてみる先ほどまではmonthが01のレコードを対象としていましたが、RANDOM()を使って求めたmonth + 1~10の整数が12になるレコードを対象として抽出してみます実行結果です今度はyear=2019のかつmonthが1~12の合計12パーティションにアクセスしていることが分かります。スキャン量も14.36MBに増えています。RANDOM()の結果が確定しないとどのパーティションを読み込むべきかAthenaのエンジンからは判断できないのでこれは妥当な動きでしょう。まとめ Athenaでクエリを実行する際WHERE句に関数を使ってもいい感じにパーティションを使ってくれることを確認しました。ちゃんとオプティマイザが最適化してくれることが分かって一安心です。とはいえあまり複雑なことをし過ぎると意図通りのアクセスパスにならない可能性もあるので、実際にクエリを書く際は「Athena破産」することが無いようにしっかりEXPLAIN ANALYZEの結果を確認しながらクエリを構築していきましょう。
https://dev.classmethod.jp/articles/athena-use-partition-when-use-function-in-where-clause/

2024-06-17 05:16:26

【[NEW]生成AIを学ぶAWSトレーニング Developing Generative AI Applications on AWS が始まります。】
AWS認定トレーニング講師の平野@おんせん県おおいたです。いよいよ7月より生成AIのトレーニングを提供開始します。このブログでは、その内容を紹介します。はじめに 2022年秋にChatGPTが話題に上って以来、生成AIが空前のブームとなり今でも拡大しています。そんな中で、多くの企業さんが生成AIに着目していると思います。その一方で、多くの情報に囲まれて迷子になりかけている方も多いのではないでしょうか。そんな方にオススメするのが本コースです。AI/機械学習の経験のない方に、生成AIの基礎を学んで頂き、進む方向を見極める力を付けて頂くトレーニングとなっています。 AWS認定トレーニング（クラスルームトレーニング）とは AWSが提供する公式のトレーニングです。クラスメソッドでは2021年から提供してきました。現在12のコースがあり、今回生成AIのコースが新たに加わりました。コースの概要 Developing Generative AI Applications on AWS は次のようなコースになります。 2日間コースラボはありません Amazon Bedrockに加え、生成AIに関する一般的な知識も学べます特にラボがないことが特徴です。手を動かす機会の少ないマネージャークラスの方も安心してご参加頂けます。また、ご参加にあたり事前に下記の知識を学んで頂くことをオススメ致します AWS Cloud Practitioner相当のAWS一般知識 AWSのセキュリティの基本あと、機械学習に関する入門知識があると理解が深まりますが、こちらは必須ではありません。どんな人にオススメ？情報システムの開発を業務とする方今後生成AI技術を活用した情報システム開発を検討している方どんな人にはオススメしない？プロンプトによる生成AIの活用事例を学びたい方機械学習モデルそのものの作成方法を学びたい方コースの詳細このコースは8つのモジュールで構成されています。各モジュールでは主に下記について学びます。 1 生成 AI の概要 - 可能性を実現する力 AIの概要を学びます機械学習の基本を学びます生成AIをどのように活用するかを考えてみます生成AIのリスクと利点について考えてみます 2 生成 AI プロジェクトの計画基盤モデルの概要を学びます生成AIメカニズムの基本であるTransformerの概要/特徴を学びます生成AIの懸念事項について整理します 3 Amazon Bedrock 入門 Amazon Bedrockの基本を学びますデモを通じて、各機能を学びます 4 プロンプトエンジニアリングの基礎基盤モデルの特徴を踏まえ、生成AI活用の基本的なアプローチを学びます手軽に活用する方法であるプロンプトエンジニアリングの概要を学びます 5 Amazon Bedrock アプリケーションコンポーネント基盤モデルのパラメータについて学びます RAGの概要を学びますファインチューニングの概要を学びます 6 Amazon Bedrock 基盤モデル Bedrockで提供されている各基盤モデルの特徴を学びます 7 LangChain を使う生成AIアプリケーション開発の標準的なツール LangChain について学びます 8 アーキテクチャパターン生成AIアプリケーションのアーキテクチャパターンについて学びます各パターン毎に、LangChainを利用したデモで理解を深めますまとめ生成AIを学ぶAWS公式トレーニングについてご紹介しました。多くのシステム開発者の、生成AIアプリケーション開発へのチャレンジにお役に立てばと思っております。クラスメソッドでは、生成AIコンサルティングを行っておりますので、合わせてご活用頂ければと幸いです。トレーニングお申し込み方法 AWSトレーニングの詳細やお申し込みは弊社公式ページよりお願い致します。おまけ余談ですが、このブログのタイトル画像はAmazon Bedrockで生成しました。最後に生成の様子をキャプチャにてご紹介します。
https://dev.classmethod.jp/articles/aws-training-gen-ai/

2024-06-17 05:13:16

【Google Colab Enterprise を操作してみた。基本操作と料金プランをわかりやすく解説。】
Google Colabとは無料のGoogle Colabを使用した経験がある方は多いかもしれません。企業のユースケースに合わせて、セキュリティやスケーラビリティ、統合性を重視したのがColab Enterpriseです。 Google Cloudサービスに統合されているプラットフォームなので、通常のGoogle Colabと比べると多様な機能が存在します。また、操作感に関してはWebで使用できる通常のGoogle Colabと変わらないため、慣れている方であればすぐに使い始められます。冒頭でも触れた通り、リージョン、VPC、組織ポリシー、IAMポリシーによるきめ細かいアクセス制御を適応させることが可能なため、セキュリティ機能などの追加の学習コストを必要とせず、Google Cloud内で実行することができます。連携先としては、Cloud Storage、BigQuery、Vertex AIなど、他のGoogle Cloudサービスとネイティブに連携し、データの取り込み、処理、モデルのデプロイまでをシームレスに実行できます。まとめると、Google Colabは企業が機械学習の力を最大限に活用するための最適なプラットフォームとなります。料金 Colab Enterpriseの料金は、仮想マシンで実行されるため、選択するマシンスペックとリージョンによって変わってきます。 CPU、メモリ、アクセラレータ、ディスク単位で課金され、以下はCPUを東京リージョンで使用した際の料金になります。メモリ、アクセラレータ、ディスクについても先ほどのColab Enterpriseの料金から算出できるので、試してみてください。触ってみた Google Cloud コンソール Colab EnterpriseはGoogle Cloud サービスの一部です。よって、Google Cloudに登録をして、コンソールにログインできる状態でなければ、使用することができません。 Google Cloudの登録方法は以下を参照してください。基本操作 Google Cloud コンソールの検索窓に[Colab Enterprise]と入力し、Vertex AIサービスの画面へ移動します。 Colab Enterpriseの操作画面になったら、ノートブックを実行する[リージョン]を確認して、[ノートブックを作成する]を押下します。ライブラリのインポートを行うために、コードを実行していきましょう。 [▶️]を押下すると、Colab Enterpriseを実行する[VPCネットワーク]を選択する画面が開きます。選択したVPCはプロジェクト作成時に自動的に作成されるデフォルトVPCネットワークです。（以下はVPCの画面）（Colab Enterpriseを実行するVPCとサブネットを設定したので、ここから実際にプロンプトに記述したコードを実行することができます。）ライブラリのインポートも完了したので、コードを実行してみましょう。 [titanic]の生存データをインスタンス化し、dfという変数に格納して、データフレームを表示させてみます。ここまでが基本の操作です。 Cloud Storageや既存のGoogle Colabからコードをインポートすることもできるので、Colab Enterpriseにコードを移行したい時には活用してください。機械学習モデルを構築してみるせっかくなので、[survive]カラムの値を予測するというモデルも作成してみます。コードの詳細は解説しませんが、ライブラリの大まかな使い方と流れについては参考になるかもしれません。データセットを分割します。文字列カラムの値をラベルエンコードします。 MinMaxScalerを使用して、数値の値のスケールを統一します。 SVCを使用して、前処理したデータを学習していきます。結果は少し過学習の傾向があります。（trainとtestの結果に差分が大きければ大きいほどとうまくいっていない） GrindSearchを使用して、ベストな値を算出します。結果が出ました。（以下の結果でハイパーパラメータを指定すれば、よりいいモデルを生み出すことができる） ※ 本来はこの値を再度SVCに設定して、GrindSearchの結果を確認しますが今回は割愛。まとめ無料のGoogle Colabとの違いセキュリティーやコンプライアンス面での有用さがあると感じました。冒頭でも書いたように、リージョンとVPCを指定でき、さらにGoogle Cloud内で実行するリソースのため、組織ポリシーやIAMポリシーにより、機能を細かく制限することが可能です。さらに、さまざまなGoogle Cloudサービスとネイティブに連携できるという特徴も欠かせません。これにより、Cloud StorageやBigQueryと連携させてデータを操作することやVertex AIの各サービスと統合させて開発することも可能です。エンタープライズという名前だけあって、企業でGoogle Colabを使用する際にはぜひ使いたいサービスだと思います。
https://dev.classmethod.jp/articles/google-colab-enterprise-basic-info/

2024-06-17 04:13:16

【AWSアカウント上のアクティビティを収集するサービス・機能をまとめてみた】
はじめに AWSを利用して構築した環境を運用管理するにあたり、あらゆるレイヤーのアクティビティがわかることは非常に重要です。というより、事実関係がわからなければあらゆるトラブルに対応することが困難になります。そこで、この記事ではアクティビティの収集にフォーカスしてAWSのサービスや機能を整理してみたいと思います。主に自分のために。なぜアクティビティを収集するのか「事実関係がわからなければあらゆるトラブルに対応することが困難」と一言で書きましたが、アクティビティが明確になることで以下の様な対応が可能のなると思います。問題の予兆を検知、予防する発生した問題の内容や原因を特定し、影響を緩和・根本的な対策を実施する問題の収束後にステークホルダーへの説明責任を果たすアクティビティに関する情報がなければ、このいずれも不可能でしょう。それでは、AWS上でアクティビティを収集するサービスおよび機能を紹介していきます。この記事の前提についてまず、この類の記事を書くと一定の割合で誤解されるのですが、ここで述べる各種の設定はすべて実施する必要はありません。要件や管理対象のワークロードに問題が起きたときのインパクト、予算などによります。アクティビティの収集自体は目的ではありません。サービスを提供する地域や業界において、法規制や各種ガイドラインがあればそれに準拠するべきでしょうし、脅威モデリング等を利用して管理対象のシステムをどのような脅威から守る必要があるかを整理した上で収集が必要なアクティビティを選択するのもよいでしょう。例 STRIDE model また、（正規のアクセスについては）IAM UserやサードパーティのIdPで発行されたIDの共有などを行っていないことを前提とします。でなければ、そのアクティビティが誰によるものなのか識別できません。アクティビティを収集するAWSサービスまずは、アクティビティを収集すること自体が目的のサービスについてまとめます。 CloudTrail Config GuardDuty CloudTrail CloudTrailにより、IAM User / IAM Role / AWS Serviceによって実行されたアクションを記録することができます。 CloudTrailで記録できるアクションはManagement EventsとData Eventsに分類されます（Insights Eventsは通常とは異なる傾向のイベント群を検知した際に記録されるものなのでここでは説明を割愛します）。 Management Eventsは証跡を作成する事で記録が開始されますが、データイベントは明示的に設定しない限り記録されません。管理するワークロードにおいて発生するデータイベントのうち、必要なもの（機密性の高いデータを操作するイベントなど）については記録することを検討しましょう。その際、記録の対象を必要以上に設定した場合に料金が高額になる可能性があるので注意してください（Data Eventsは、使い方次第ですが一般的には大量に発生します）。 Logging data events ちなみに、マネージメントコンソールでデータイベントの取得設定をしようとするとS3 / DynamoDB / Lambdaのみがサポート対象であるように見えるかもしれませんが、実際には他のサービスにも対応しています（Advanced Event Selectorを利用して設定できます）。詳細はドキュメントを確認してください。 Data events CloudTrailの証跡を作成することで、S3にログを収集する事ができます（CloudTrail Lake / Security Lake等の選択肢については割愛）。 Creating a trail for your AWS account 大半のAWSサービスに関するアクションを記録する事が可能です（すべてではありません）。 AWS service topics for CloudTrail サポートしているサービスにおいてどのイベントの記録をサポートしているのかはドキュメントに明記されているので、必要に応じて確認してください。 S3の例 Amazon S3 CloudTrail events もっと広範な情報を簡単に確認したい場合には弊社ブログの記事も併せてどうぞ。 AWS入門ブログリレー2024〜AWS CloudTrail編〜 Config Configにより、AWSリソースの現在および過去の構成や他のリソースとの関係を記録することができます。構成の変更操作自体はCloudTrailでも記録されますが、AWSリソースを軸にその変化を確認する事ができるのでCloudTrailと併せて利用する事をおすすめします。記録を有効化することで、AWSリソースの構成に関する情報をS3に記録することができます。 Getting Started with AWS Config サポートされるリソースはすべてではないので、必要に応じて確認しましょう。 Supported Resource Types 弊社ブログの記事も併せてどうぞ。 AWS入門ブログリレー2024〜AWS Config編〜 GuardDuty 純粋なアクティビティの収集とは異なりますが、重要なサービスなので言及します。 GuardDutyは脅威検知を行うマネージドサービスです。 CloudTrailのManagement Events / DNS Log […]
https://dev.classmethod.jp/articles/collect-activity-on-aws/

2024-06-17 03:13:16

【AWS IoT MQTT のライフサイクルイベントの versionNumber がリセットされるタイミングを教えてください】
困っていた内容 AWS Iot Core のライフサイクルイベントを監視しています。ライフサイクルイベントの中身を確認すると、バージョン番号（versionNumber）がリセットされていることがあります。どのようなタイミングでライフサイクルイベントのバージョン番号がリセットされるのか教えてください。どう対応すればいいの? 永続セッションの設定の有無によって、バージョン番号のリセットの仕様は異なります。・永続セッションが設定されていないデバイス：クライアントの接続が約 1 時間以上切断されると、バージョン番号は 0 にリセットされます。・永続セッションが設定されているデバイス：永続セッションの time-to-live (TTL) よりも長くクライアントが切断されると、バージョン番号は 0 にリセットされます。なお、永続セッションの TTL の最大値は 7日間です（2024.6 現在）。ライフサイクルイベント - AWS IoT Core クライアントが約 1 時間接続されない場合、バージョン番号は 0 にリセットされます。永続セッションでは、永続セッションに設定されている time-to-live (TTL) よりも長くクライアントが切断されると、バージョン番号は 0 にリセットされます。参考資料ライフサイクルイベント - AWS IoT Core MQTT - AWS IoT Core AWS IoT Core エンドポイントとクォータ - AWS 全般のリファレンス
https://dev.classmethod.jp/articles/tsnote-iotcore-mqtt-versionnumber-reset/

2024-06-16 07:19:33

【[アップデード]IAM Access Analyzerのカスタムポリシーチェックでパブリックアクセスと重要リソースアクセスのチェックが追加されました！ #AWSreInforce】
こんにちは、臼田です。みなさん、アクセス権限のチェックしてますか？(挨拶今回はAWS re:Infore 2024にてIAM Access Analyzerのカスタムポリシーチェックが拡張されたので解説します。 AWS IAM Access Analyzer now offers policy checks for public and critical resource access - AWS IAM Access Analyzer Update: Extending custom policy checks & guided revocation | AWS News Blog カスタムポリシーチェックとは？ IAM Access Analyzerのカスタムポリシーチェックは前回のre:Invent 2023にて発表された機能です。 AWSを利用している際にはアクセス制御のために様々なポリシーを記述して利用します。例えばIAM UserやRoleに対して権限をアタッチするアイデンティティベースポリシー(IAM Policyやインラインポリシーなどのアクセス許可ポリシー)や、S3やIAM Roleに誰が(何が)アクセスすることを許可するか設定するためのリソースベースポリシー(S3: バケットポリシー、IAM Role: 信頼ポリシー)があります。通常、新たに権限を追加したり、それを変更する作業は特権に近い作業ですから、誰でも簡単にできると困りますよね。然るべき人のチェックを受けながら、新しいユーザーのために権限を払い出したり、サービスにアタッチされた権限を慎重に変更していきます。ではそのレビューは本当に正しく実行できるでしょうか？ポリシードキュメントはjsonで記述されていて複雑です。人の目でチェックしていると、ヌケモレがあるかもしれません。行数が減っている代わりに新しい権限が追加されていることが見逃されているかもしれません。diffを取ったらどうでしょうか？表記ブレや順番の変更など単純なdiffだと見なくていい場所が増えたりして、だんだんレビューが煩雑になるかもしれません。Allowだけ記述されていたポリシーから、AllowとDenyを組み合わせた別の表現方法にしたとき、それは本当に以前より権限が絞られているでしょうか？そんなときに利用できる機能がカスタムポリシーチェックです！最初のリリースの際には下記2つのチェックが可能でした。 CheckNoNewAccess 新旧のポリシーを比較して、新しいアクセスが許可されているか確認する権限を変更する際に権限が増えていないかという観点のチェックができる権限が増えていないことを担保したり、増えていた場合にレビューのレベルを上げるなどの運用に利用できるアイデンティティベースポリシーとリソースベースポリシー両方に適用可能 CheckAccessNotGranted 単体のポリシーに対して指定したアクション(権限)が含まれているか確認する与えたくない権限を与えていないか確認できる特に変更系や削除系の権限などが含まれていないことを担保できるアイデンティティベースポリシーとリソースベースポリシー両方に適用可能これらは自動推論を利用して、数学的に裏付けされたチェックがされるため、単純なdiffや目視での確認では担保しづらい確認を行えます。それぞれポリシーを実際のAWSリソースに展開する前に、ポリシードキュメントなどだけでチェックが可能なため、CI/CDのフローなどに組み込み、事前のチェックに利用可能です。今回のアップデートでは、新しくCheckNoPublicAccessというチェックが加わり、CheckAccessNotGrantedに指定したリソースへのアクセスが含まれていないか確認できるようになりました。順番に見ていきましょう。 CheckNoPublicAccess 名前の通り、パブリックアクセスが含まれていないかチェックできます。 check-no-public-access — AWS CLI 2.16.9 Command Reference ざっくり説明は以下の通りです。単体のポリシーに対してパブリックアクセスが許可されていないか確認する外部に公開すべきでないリソースが確実に公開されていないことを担保できるリソースベースポリシーに適用可能現状対応しているリソースは以下の通り AWS::DynamoDB::Table AWS::DynamoDB::Stream AWS::EFS::FileSystem AWS::OpenSearchService::Domain AWS::Kinesis::Stream AWS::Kinesis::StreamConsumer AWS::KMS::Key AWS::Lambda::Function AWS::S3::Bucket AWS::S3::AccessPoint AWS::S3Express::DirectoryBucket AWS::S3::Glacier AWS::S3Outposts::Bucket AWS::S3Outposts::AccessPoint AWS::SecretsManager::Secret AWS::SNS::Topic AWS::SQS::Queue AWS::IAM::AssumeRolePolicyDocument かなり幅広く対応していますね。おそらくリソースベースポリシーに対応していて外部公開が可能なリソースはすべて含んでいるのではないでしょうか？(たぶん、直感的にそんな気がします、調べてないけど) 利用していきたい主要なリソースはS3バケット、Lambdaあたりでしょうか。知らない間に公開されていると非常に困りますから、これを自動推論でチェックして担保できるのは非常に心強いです。実際に使ってみましょう。今回はS3バケットが公開されていないか確認してみましょう。その前に、CloudShellを立ち上げてAWSCLIのバージョンをチェックします。バージョンが古いですね。どうやらAWSCLIは2.16.6から本機能に対応していそうなので、バージョンを上げておきます。 AWS CLIの最新バージョンのインストールまたは更新 - AWS […]
https://dev.classmethod.jp/articles/iam-access-analyzer-check-public-access-and-resource-access/

2024-06-13 06:13:16

【問題の明確化 – 粒度の粗い問題】
こんにちわ。組織開発がミッションの人事グループ・組織開発室に所属しているてぃーびーです。仕事において、大小さまざまな問題が存在します。誰かが問題について話すとき、すぐに解決に向けて取り組むことができるとは限りません。問題を解決していく前に、問題の明確化が必要なケースがあります。この記事では、「問題の明確化」に関する「粒度の粗い問題」について説明します。粒度の粗い問題問題提起をしてくれているが、内容の粒度が粗く、具体的に何を問題としているのか把握出来ないケースです。「粒度の粗い問題」を整理する対応として、具体的に何を問題として捉えたのかを確認する必要があります。曖昧な情報を具体化する粗い粒度で伝えられた問題は、実際に起った個別の出来事を伝える過程で表現が大雑把になり、曖昧に伝わっています。そのため、大雑把な表現に丸められる前の具体的な出来事に関する情報を引き出す必要があります。例えば、Aさんがあるシステムの顧客一覧を見ていたとします。「画面内の文字のサイズが小さく見えにくい」「文字と背景色のコントラストが低くて読みにくい」「一覧の項目名の名称が分かりにくい」など、具体的なわかりにくさを3つ経験し、システムの開発者に「顧客一覧が分かりにくい」とだけ伝えたとします。それだけを聞いても開発者はどの部分のことを言っているかわかりません。この場合、具体的にどのような操作をしていたときに、どのような部分に対して分かりにくかったのかを質問して一つずつ引き出すことで、上に上げた「画面内の文字のサイズが小さく見えにくい」などの具体的な問題を把握することができます。問題の掘り下げ方については「共通の対応」にまとめた内容で問題の詳細を確認していくことになります。共通の対応「粒度の粗い問題」のケースに限らず、問題を整理するうえで共通のポイントとして、「問題の背景にある具体的で詳細な情報を集める」という行動が必要になります。システムの開発において顧客の要求の情報が不足している際や、営業において顧客のニーズ・ウォンツの情報が不足している際に行うヒアリングと同じような取り組みにあたります。情報を引き出す際には事実を引き出すことが重要です。When、Where、Who、What、Howなどの質問によって事実を問うのが有効です。逆に「なぜ」「どうして」などの質問は事実ではなく、解釈を引き出しやすくなります。解釈は事実と一致しているとは限らないため問題の本質からそれてしまう可能性があります。まとめ「問題の明確化」に関する「粒度の粗い問題」について説明しました。粒度の粗い問題だけを伝えられ、内容を明確にしないまま解決策を実施した場合、問題を正しく捉えた解決策と比較した場合、的確ではない解決策を選ぶことで無駄足になったり、要点を外した解決策を選ぶことで費用対効果が薄い取り組みになりかねません。問題を明確にしてから解決策を検討しましょう。関連情報問題処理入門問題と課題を区別する | DevelopersIO その問題は本当に1つなのか？ | DevelopersIO 問題解決における対症療法と根本対応 | DevelopersIO 問題の明確化 – 全体像 | DevelopersIO
https://dev.classmethod.jp/articles/ambiguous-problem/

2024-06-07 00:13:16

【Amazon Connectと生成AIについて、「コールセンター/CRM デモ＆コンファレンス 2024 in 大阪」で登壇しました】
はじめに 2024年5月29日（水）～30日（木）に大阪にて「コールセンター/CRM デモ＆コンファレンス2024 in 大阪」が開催され、弊社はブース出展とセミナー登壇を行いました。私は、5月30日（木）に「【Ama […]
https://dev.classmethod.jp/articles/amazon-connect-240529-callcenter-osaka/

2024-06-06 06:13:16

【[2024年6月6日号]個人的に気になったModern Data Stack情報まとめ】
さがらです。 Modern Data Stack関連のコンサルタントをしている私ですが、Modern Data Stack界隈は日々多くの情報が発信されております。そんな多くの情報が発信されている中、この2週間ほどの間 […]
https://dev.classmethod.jp/articles/modern-data-stack-info-summary-20240606/

2024-06-06 05:16:26

【VisionOneのServiceGatewayにActiveDirectoryを接続してみた】
こんにちは、シマです。皆さんはTrend Vision Oneを使っていますか？先日、Trend Vision Oneがサードパーティアプリケーションと連携するために必要なService Gatewayと呼ばれる仮想ア […]
https://dev.classmethod.jp/articles/202406-v1-servicegateway-ad-01/

2024-06-05 07:22:44

【Data Cloud Summit 2024の「PLATFORM KEYNOTE」で発表された内容に関する公式情報まとめ #SnowflakeDB #SnowflakeSummit #DataCloudSummit】
さがらです。 Snowflakeの年次最大のイベントとなる「Data Cloud Summit 2024」が現地時間2024年6月3日～6日で開催しております。この内、2024年6月4日の「PLATFORM KEYNO […]
https://dev.classmethod.jp/articles/data-cloud-summit-24-platform-keynote-summary-blog-and-youtube/

2024-06-05 07:13:16

【Flutterでネットワーク接続状態を確認して分岐させてみた（connectivity_plus）】
こんにちは、ゲームソリューション部のsoraです。今回は、Flutterでネットワーク接続状態を確認して分岐させてみた（connectivity_plus）ことについて書いていきます。実装した画面ネットワーク接続状 […]
https://dev.classmethod.jp/articles/flutter-connectivity/

2024-06-05 06:16:23

【【社員インタビュー #4】SaaS導入で企業を支援する「サーバーサイドエンジニア」いりいさんに色々聞いてみた！】
みなさん、こんにちは。クラスメソッド採用担当の徳山です。今回の社員インタビューはクラスメソッドのSaaS導入コンサルティング事業において「サーバーサイドエンジニア」としてご活躍されているいりいさんにインタビューさせてい […]
https://dev.classmethod.jp/articles/interview_irii/

2024-06-05 06:13:16

【CX事業本部SBJソリューション部にジョインしたserinaです！】
2024年6月よりCX事業本部SBJソリューション部にジョインしました、serinaです。自己紹介異業種転職して、今年でエンジニア5年目になりました。文化服装学院を卒業してアパレル企業で生産管理を約2年経験した後、 […]
https://dev.classmethod.jp/articles/joined-serina/

2024-06-05 04:19:32

【クラスメソッドデータアナリティクス通信(機械学習編) – 2024年6月号】
データアナリティクス事業本部インテグレーション部機械学習チームの鈴木です。クラスメソッドデータアナリティクス通信(機械学習編) の2024年6月号です。2024年5月分のアップデート情報をお届けできればと思います […]
https://dev.classmethod.jp/articles/cm-da-news-ml-202406/

2024-06-05 04:16:26

【Snowflakeに取り込んだJSONデータをクエリして展開したい】
データアナリティクス事業本部の荒木です。 Snowflakeに取り込んだJSONデータの各項目をSQLで簡単にテーブルに展開することができとても便利だったのでご紹介します。本題 SnowflakeではVARIANT型に […]
https://dev.classmethod.jp/articles/snowflake_json_query/

2024-06-05 04:13:16

【Windows で AWS CLI のエラー「Unknown options:」を回避するには】
困っていた内容 Windows のコマンドプロンプトで AWS CLI を実行するとUnknown options:エラーが表示されます。バージョンが古いのかと思い AWS CLI を最新版に更新しましたが、解消しませ […]
https://dev.classmethod.jp/articles/tsnote-windows-aws-cli-error-unknown-options/

2024-06-05 03:13:16

【Amazon RDS の MariaDB、MySQL、PostgreSQL エンジンの M4、R4、T2 インスタンスタイプのサポート終了について公式ドキュメントに追記されていたのまとめてみた】
いわさです。 RDS インスタンスタイプの廃止について既に把握されている方も多いと思いますが、Amazon RDS の MariaDB、MySQL、PostgreSQLにおいて旧インスタンスである T2、M4、R4 のサ […]
https://dev.classmethod.jp/articles/rds-mysql-psql-m4-r4-t2-end/

2024-06-04 19:16:26

【App Runner環境で生じた障害調査とAWS WAFによる暫定対策を実施しました】
6/4 10:30 〜 11:50 (JST) App Runner 環境で発生した、遅延とエラー率が上昇する事象について、実施した対応について紹介させていただきます。 App Runner App Runnerのダッシ […]
https://dev.classmethod.jp/articles/app-runner-down-recovery/

2024-06-04 19:13:16

【[小ネタ] RDS にリードレプリカが含まれていると停止できません】
コーヒーが好きな emi です。タイトルがすべてなのですが、RDS にリードレプリカが含まれていると停止できません。リードレプリカ自体も停止できませんし、リードレプリカの元となっているソース DB も停止できません。 […]
https://dev.classmethod.jp/articles/read-replicas-cannot-be-stopped/

2024-06-04 11:19:29

【[まるクラ勉強会 ONLINE #2]AWSマルチアカウント環境におけるAWS CloudTrailの管理戦略】
あしざわです。先日行われた、まるクラ勉強会 ONLINE #2 - AWS&Google Cloudの環境分離戦略編 - にて、『AWSマルチアカウント環境におけるAWS CloudTrailの管理戦略』という […]
https://dev.classmethod.jp/articles/marucla2-cloudtrail-management-in-multiaccount/

2024-06-04 11:16:24

【クラスメソッドのReact事情大公開スペシャル#3 -「高速案件立ち上げで使われるマッハテンプレートのフロントエンド技術選定」というテーマで登壇しました #クラスメソッド勉強会】
西田@リテールアプリ共創部マッハチームです先日、大阪で行われたクラスメソッドのReact事情大公開スペシャル#3で「高速案件立ち上げで使われるマッハテンプレートのフロントエンド技術選定」というタイトルで発表させてい […]
https://dev.classmethod.jp/articles/frontend-tech-selection-react/

2024-06-04 04:13:16

【【8/7（水）】今すぐ実践できる、AWSセキュリティ対策のススメ】
【8/7（水）】今すぐ実践できる、AWSセキュリティ対策のススメ
https://dev.classmethod.jp/news/240807-aws-security-webinar/

2024-06-04 00:13:16

【[アップデート] AWS Elastic Beanstalk の .NET on Linux プラットフォームでもようやく .NET 8 がサポートされました】
いわさです。 AWS Elastic Beanstalk ではいち早く .NET on Windows Server プラットフォームで .NET 8 のサポートが始まっていたことを以前紹介しました。他のどの AWS […]
https://dev.classmethod.jp/articles/beanstalk-dot-net-8-al2023/

2024-06-03 15:16:26

【Cloud Run ジョブの並列実行方法について考えてみた】
最近Cloud Run ジョブと真摯に向き合っている、データアナリティクス事業本部の根本です。皆さんはCloud Run ジョブで並列処理を行なってバッチ処理の所要時間を短縮したいと思ったことはありませんか？今回はCl […]
https://dev.classmethod.jp/articles/20240603-cloudrunjobs-plt/

2024-06-03 12:19:35

【『〜AWS初心者向け〜　ベストプラクティスから学ぶ「AWSセキュリティの高め方」』というタイトルで登壇しました】
こんにちは、AWS事業本部のこーへいです。先日開催しましたAWSを最大活用するための1dayカンファレンスにて、『〜AWS初心者向け〜　ベストプラクティスから学ぶ「AWSセキュリティの高め方」』というタイトルお話し […]
https://dev.classmethod.jp/articles/aws-security-best-practices-for-beginners/

2024-06-03 11:29:04

【AWS Secret Manager の利用を検討しています。大量アクセスが発生する想定ですがパフォーマンスの問題は発生しますか？】
困っていること AWS Secret Manager の利用を検討しています。シークレットを多くの場所から取得する予定ですが、パフォーマンスの問題は発生しますか？どう解決すればいいの？ 10,000/秒のリクエスト […]
https://dev.classmethod.jp/articles/tsnote-aws-secret-manager-quota-001/

2024-06-03 11:22:44

【【リファラル採用インタビュー #3】同級生からの紹介で拓けた、新しい営業の働き方】
こんにちは、クラスメソッド採用チームの新美です。クラスメソッドではリファラル（社員紹介）採用で多数の社員が入社しています！実際にどんな流れで紹介～入社に至ったのか、インタビュー形式でご紹介する本連載。第三回は、新納 […]
https://dev.classmethod.jp/articles/referral_3/

2024-06-03 03:16:23

【クライアント PC の Windows7 OS は S3 File Gateway でサポートされていますか】
困っていること S3 File Gateway を SMB クライアントで使用しています。Windows7 のクライアントPC にて S3バケットとファイル共有を行ったところ、マウントコマンド実行時に以下のエラーよりでき […]
https://dev.classmethod.jp/articles/tsnote-storage-gateway-s3-file-smb-windows7-clients-support/

2024-06-03 03:13:16

【Snowflake Trust Center を試してみた #SnowflakeDB】
2024年5月のリリースで Snowsight 上で Snowflake アカウントのセキュリティリスクを評価、監視できる機能である Trust Center がパブリックプレビューとなりました。こちらの機能を試してみ […]
https://dev.classmethod.jp/articles/snowflake-trust-center-pupr-try-snowflakedb/

2024-05-31 03:13:16

【Classmethod Odysseyの歩き方〜イベント参加登録編〜 #cm_odyssey】
先日2024年05月28日、クラスメソッド設立20周年を記念して行われる"史上最大のテックとビジネスの祭典"、『Classmethod Odyssey』のイベント登録サイトが公開されました！今回のこの『Classmet […]
https://dev.classmethod.jp/articles/how-to-walk-in-classmethod-odyssey-event-registration-edition/

2024-05-30 09:13:16

【Amplify Data（Gen2）からMySQL接続を試してみた】
NTT東日本の中村です。 Amplify Gen2では、プレビュー版では行えなかったAmplify DataでのMySQL接続ができるようになり、調査を行ってみました。 Amplify Data（Gen2）のMySQL接 […]
https://dev.classmethod.jp/articles/amplify-gen2-data-mysql/

2024-05-28 03:16:25

【[レポート]Road to SRE NEXT 2024@福岡に参加してきた #srenext】
SRE NEXT 2024について信頼性に関するプラクティスに深い関心を持つエンジニアのためのカンファレンス「SRE NEXT 2024」が2024年8月3日〜4日の2日間にわたってAbema Towersで開催されま […]
https://dev.classmethod.jp/articles/report-on-road-to-sre-next-fukuoka-2024/

2024-05-27 12:13:16

【Cloud Run ジョブについて調査してみた(基礎編)】
データアナリティクス事業本部の根本です。娘がそろそろ3ヶ月になり、笑ったりぬいぐるみを目で追ったりするようになるなど成長の速さを感じる最近です。そしていつか親元を離れていくんだろうな、、と思うと黄昏時の気持ちになります。 […]
https://dev.classmethod.jp/articles/20240527-cloudrunjobs/

2024-05-27 07:13:16

【Cost Optimization HubのレコメンデーションをEventBridge Scheduler+Lambdaで定期通知してみた】
こんにちは！AWS事業本部のおつまみです。みなさん、コスト削減のためのレコメンデーション（推奨事項）を定期的に通知してほしいなと思ったことはありませんか？私はあります。コスト削減は多くのAWS利用ユーザーにとって重要 […]
https://dev.classmethod.jp/articles/cost-optimization-hub-notification/

2024-05-27 04:19:36

【ทดสอบ AWS IoT Greengrass ด้วย Raspberry Pi พาร์ท 1/2 : การติดตั้ง AWS IoT Greengrass】
สวัสดีครับ ต้าครับ วันนี้ผมจะมาทดสอบ ทดลองใช้งาน AWS IoT Greengrass จริงๆกันครับ โดยในพาร์ท 1/2 นี้จะเป็นบทควา […]
https://dev.classmethod.jp/articles/aws-iot-greengrass-with-raspberry-pi-part-1-install/

2024-05-27 03:13:16

【IoT ruleでルーティングに失敗した際のトラブルシューティングしてみた】
はじめに新しいIoT ruleを作成した時、IoT ruleの設定を変更した時、その他諸々... IoT ruleの設定ミスでルーティングがうまくいかないことはありませんか？そんな時、ささっとトラブルシューティングし […]
https://dev.classmethod.jp/articles/iotrule_error_troubleshooting/

2024-05-27 00:13:16

【Amazon AppStream 2.0の各設定項目を解説しつつ、Quick Linksのサンプルアプリケーションをセットアップしてみた】
はじめに Amazon AppStream 2.0の各設定項目を解説しつつ、Quick LinksでAWSが提供するサンプルアプリケーションをセットアップしてみました。 AppStream 2.0は、デスクトップアプリケ […]
https://dev.classmethod.jp/articles/amazon-appstream-2-quick-links/

2024-05-24 13:13:16

【Trinity のパフォーマンスモニタリング機能を Apptainer で動く Trinity コンテナで試してみた】
Triity には解析実行中のリソースの使用率レポートを出力できるオプション（--monitoring）があります。 Apptainer で起動する Trinity コンテナでも利用可能か試してみました。 Trinity […]
https://dev.classmethod.jp/articles/performance-monitoring-in-trinity-with-apptainer-containers/

2024-05-24 03:13:16

【FlutterからCloud Functions for Firebase（Python）経由でOpen AIのAPIを使ってみた】
こんにちは、ゲームソリューション部のsoraです。今回は、FlutterからCloud Functions for Firebase（Python）経由でOpen AIのAPIを使ってみたことについて書いていきます。 […]
https://dev.classmethod.jp/articles/firebase-functions-flutter-openai/

2024-05-22 21:13:16

【[アップデート] Amazon SES に新機能 Mail Manager が追加されました】
いわさです。先日 Amazon SES を眺めていたら何やら見たことのない機能が追加されていました。なんか新しいの登場したな。Mail Manager pic.twitter.com/6wIyviNuiB &mdas […]
https://dev.classmethod.jp/articles/ses-mail-manager/

2024-05-19 02:16:26

【AWS Deadline Cloudを利用してクラウドレンダリングしてみた】
こんにちは、ゲームソリューション部の出村です。先日AWS Deadline Cloudがリリースされましたが、このエントリーではAWS Deadline Cloudでレンダーファームを構築していきます。その前に、AW […]
https://dev.classmethod.jp/articles/cloud-rendering-with-aws-deadline-cloud/

2024-05-17 18:13:45

【Trinity 中間ファイルの保存先ストレージの違いで処理時間に影響あるのか確認してみた】
Trinity は RNA-Seq データの de novo アセンブリで広く使われるアプリケーションです。本記事では、中間ファイルの保存先ストレージが実行パフォーマンスに与える影響を検証します。具体的には、インスタンス […]
https://dev.classmethod.jp/articles/how-storage-affects-processing-time-for-trinity-intermediate-files/

2024-05-16 08:13:45

【RDS for Oracle マテリアライズドビューを使用してデータを移行をしてみた】
本ブログではOracle DBをマテリアライズドビューを利用してデータを移行する方法をまとめました。移行方法は下記のページを参考しています。アジェンダ検証環境の作成とサンプルデータ作成 Oracleのユーザーアカウ […]
https://dev.classmethod.jp/articles/lim-oracle-materialized/

2024-05-16 03:13:45

【Cloud Runのチュートリアルを試してみた】
データアナリティクス事業本部の根本です。現在Cloud Runを深掘りしていて、その過程でチュートリアルも試してみました。これからCloud Runを動かしたい、という方は読んでみてください。この記事の対象者 Clou […]
https://dev.classmethod.jp/articles/20240516-cloudruntl/

2024-04-29 23:13:45

【[アップデート] AWS Firewall Manager で組織のポリシーとしてネットワーク ACL も管理できるようになりました】
いわさです。 AWS Firewall Manager みなさん使ってますか。 AWS Organizations 環境における、ファイアウォールリソース（AWS WAF、Shield Advanced、セキュリティグル […]
https://dev.classmethod.jp/articles/firewall-manager-nacls/

2024-04-28 09:13:45

【[アップデート]Knowledge bases for Amazon Bedrock で複数データソースがサポートされました】
こんにちは、つくぼし(tsukuboshi0755)です！今まで単一のデータソースしか設定できなかったKnowledge Bases for Amazon Bedrockに対して、以下のアップデートにより複数のデータソ […]
https://dev.classmethod.jp/articles/knowledge-bases-for-amazon-bedrock-multiple-data-sources/

2024-04-27 12:13:45

【Knowledge bases for Amazon Bedrock を HashiCorp Terraform で作ってみる】
こんにちは！ AWS 事業本部コンサルティング部のたかくに（@takakuni_）です。今回はタイトルの通り、 Knowledge bases for Amazon Bedrock を HashiCorp Terra […]
https://dev.classmethod.jp/articles/create-knowledge-bases-for-amazon-bedrock-via-terraform/

2024-04-27 10:13:45

【システムログに Cannot open access to console, the root account is locked. のエラーが出力され接続できない】
困っていた内容インスタンスに接続しようとしても応答がありません。コンソールからシステムログを確認すると「Cannot open access to console, the root account is locke […]
https://dev.classmethod.jp/articles/%e3%82%b7%e3%82%b9%e3%83%86%e3%83%a0%e3%83%ad%e3%82%b0%e3%81%ab-cannot-open-access-to-console-the-root-account-is-locked-%e3%81%ae%e3%82%a8%e3%83%a9%e3%83%bc%e3%81%8c%e5%87%ba%e5%8a%9b%e3%81%95/

2024-04-27 05:13:45

【AWS ParallelCluster で Apptainer と Moutpoint for Amazon S3 の組み合わせて Trinity を実行してみた】
AWS ParallelCluster 環境において Apptainer と Mountpoint for Amazon S3 を利用し、S3 をストレージとして利用した Trinity の実行方法を検証します。確認結 […]
https://dev.classmethod.jp/articles/combining-apptainer-and-s3-to-run-trinity-on-aws-parallelcluster/

2024-04-26 11:16:55

【PagerDuty Runbook Automationとは】
現在自分が所属している運用保守チームでは、PagerDutyを活用して業務の効率化を目指しています。最近PagerDuty Runbook Automationの無料トライアルを試す機会があったので、このサービスが何なの […]
https://dev.classmethod.jp/articles/pagerduty-runbook-automation%e3%81%a8%e3%81%af/

2024-04-26 05:16:55

【[初心者向け]pandasでCloud StorageのCSVファイルを読み込んでみた】
データアナリティクス事業本部の根本です。Cloud Functionsでpandasを用いてCloud Storageのファイルを読み込んでみました。2種類の読み込み方法を検証しています。そして読み込んだデータをparq […]
https://dev.classmethod.jp/articles/20240426-pandas-readcsv/

2024-04-26 05:13:45

【リモートワークでの意思疎通に困らないためのコミュニケーションテクニックn連発】
こんにちは！越後長岡から「ふるさと勤務」というなのフルリモートワークを続けて早6年目になる髙野です。ここ数年世の中の流れとしてリモートワーク中心の働き方をする方が増えたのではないかと思います。しかし、リモートワークで […]
https://dev.classmethod.jp/articles/fluent-communication-technique-for-remotework/

2024-04-26 00:13:45

【Amazon Connectから呼び出すLambdaのタイムアウト対策（DynamoDBを使ったステータス管理）】
はじめに Amazon Connectから呼び出すAWS Lambdaのタイムアウト対策を、DynamoDBを使ったステータス管理で実現する方法をまとめました。 Amazon ConnectのフローからLambda関数を […]
https://dev.classmethod.jp/articles/amazon-lambda-timeout-status-check/

2024-04-25 13:16:55

【NW X Security JAWS勉強会#3レポート #nwsecjaws3 #jawsug】
こんにちは、臼田です。伝説のNW-JAWSとSecurity-JAWSのコラボ勉強会が満を持して3回目の開催をしましたのでレポートします。 NW X Security JAWS勉強会#3 - connpass 動画後 […]
https://dev.classmethod.jp/articles/network-security-jaws-report-03/

2024-04-24 15:13:45

【Amazon Connect Customer Profilesのデータソース自動更新と更新時間変更について】
こんにちは、洲崎です。 Amazon Connect Customer Profilesで同期しているデータソースの自動更新と、更新時間の変更について調べてみたので紹介します。 Amazon Connect Custom […]
https://dev.classmethod.jp/articles/amazon-connect-customer-profiles-data-sources-update/

2024-04-24 11:13:45

【영어판 Windows Server 2022를 한국어로 변경 하는 방법에 대해 알아보자!】
소개 안녕하세요! 클래스메소드 금상원 입니다. 이번 블로그에서는 영어판 Windows Server 2022를 한국어 설정 하는 방법에 대해 알아보겠습니다. 한국어 설정 하기 「시작」에서「Settin […]
https://dev.classmethod.jp/articles/english-windows-server-2022-korean-lang-change/

2024-04-24 08:16:55

【การเรียกใช้ AWS Lambda หลังจาก AWS Glue Crawler รวบรวมข้อมูล】
บทความนี้แปลมาจากบทความที่เป็นภาษาญี่ปุ่นที่ชื่อว่า AWS Glue crawler のクロールが終わったら Lambda を実行する โดยเจ้าของบทความ […]
https://dev.classmethod.jp/articles/run-lambda-after-glue-crawler-succeeded-th/

2024-04-23 22:13:45

【AWS入門ブログリレー2024〜Agents for Amazon Bedrock編〜】
みなさん、こんにちは！福岡オフィスの青柳です。当エントリは弊社AWS事業本部による『AWS入門ブログリレー 2024』の30日目のエントリです。このブログリレーの企画は、普段AWSサービスについて最新のネタ・深い/ […]
https://dev.classmethod.jp/articles/introduction-2024-agents-for-amazon-bedrock/

2024-04-23 14:16:55

【クライアントと ALB の TLS バージョンネゴシエーションの様子を Wireshark で確認してみた】
いわさです。 AWS のサービスを使って SSL/TLS 終端を行う時に、TLS 1.3 を使えるサービスが増えてきました。そこで、先日は現時点で各サービスの TLS プロトコルのサポート状況をまとめてみました。 TL […]
https://dev.classmethod.jp/articles/alb-tls-version-negotiation/