こんにちはPS/SLの佐々木です。 今回はバージョン管理ツールasdfを使ってみようと思います https://asdf-vm.com/guide/introduction.html asdfとは asdfとはツールのバージョンマネージャーです。 従来は言語ごとにnvmやrenv pyenvなどバージョン管理ツールを使用していたと思います。 しかしasdfを使用するとこれらのバージョン管理ツールは不要になり全てasdfで管理できるようになります。 私もnode.jsのバージョン管理にnodenv, n, nvmなど一つの言語で複数のバージョン管理ツールが共存していると言う非常にカオスなローカル環境が出来上がっていたり、久しぶりに触る言語で何のバージョン管理ツールを使用していたのか調べるのが面倒だったりと色々悩まされていましたが、asdfで全て解決されそうな予感。。。 インストール方法 https://asdf-vm.com/guide/getting-started.html#_1-install-dependencies 今回はMacbookを使用したInstall方法を紹介します。 そのほかのインストール方法は上記のリンクを参考にinstallしてみてください。 brew install asdf 今回はzshにhomebrewでinstallしているので以下のコマンドを実行します echo -e "\\n. $(brew --prefix asdf)/libexec/asdf.sh" >> ${ZDOTDIR:-~}/.zshrc 基本的な使い方 特定のバージョンの言語を使えるようにするまでに以下のようなステップを踏みます pluginのインストール 利用可能なバージョンのチェック 使用したいバージョンのインストール 現在使用されているバージョンの確認 ローカルのバージョン設定 グローバルでのバージョン設定 今回はgoを使えるようにします。 まず使用できるpluginの一覧を調べます。 一覧を全て表示すると非常に多いのでgrepしています。 asdf plugin list all | grep golang golang *<https://github.com/asdf-community/asdf-golang.git> golangci-lint <https://github.com/hypnoglow/asdf-golangci-lint.git> golangのプラグインを導入します asdf plugin add nodejs h[ttps://github.com/asdf-community/asdf-golang.git](<https://github.com/asdf-community/asdf-golang.git>) installすることができるgoのバージョンを調べます asdf list all golang とりあえず最新バージョンのgoをinstallしてみましょう asdf install golang latest installできました！ asdf list golang *1.23.3 goのバージョンを確認してみたのですが、go command not foundということでどうやらパスが通ってないっぽいので以下のコマンドを実行します export PATH="$HOME/.asdf/shims:$PATH" これで再度goのバージョンを確認します go version go version go1.23.3 darwin/amd64 うまくいきました！ go version go version go1.23.3 darwin/amd64 ではバージョンを切り替えてみます。 少し古いバージョンのgolangをinstallします asdf install golang 1.19.4 installできました asdf list golang 1.19.4 *1.23.3 まだバージョンはlatestのままですね。 go version go version go1.23.3 darwin/amd64 バージョンを切り替えます asdf global golang 1.19.4 go version go version go1.19.4 darwin/amd64 かわっていますね！ 応用 複数のプロジェクトを並行して行なっている場合にプロジェクトに応じでバージョンを切り替えたいですよね。 そのような場合にasdfではディレクトリ単位でバージョンを管理することができます。 適当にディレクトリを作ってバージョンをセットしてみます。 mkdir gopj && cd gopj asdf local golang latest go version このようにすると .tool-versions というファイルが作成されます。 このファイルにはツールのバージョンが記載されています。 ls -la -rw-r--r--@ 1 kantasasaki staff 14 Nov 29 15:44 .tool-versions cat .tool-versions golang 1.23.3 ディレクトリを元に戻すとgoのバージョンがglobalに設定していたものに戻っています。 ちゃんとプロジェクトごとにシームレスにバージョン管理がされていることが確認できました。 cd ../ go version go version go1.19.4 darwin/amd64 まとめ 今回はasdfの簡単な使い方について解説しました。 複数のツールのバージョンを一括で管理することができ、さらにプロジェクトごとに使用したいバージョンをシームレスに管理できるのは非常に素晴らしいですね。 これからの人生asdfと共に歩んでいこうと思いました。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post バージョン管理ツールasdfを使ってみた first appeared on SIOS Tech. Lab .

ご挨拶 ども！弊社もアドベントカレンダーを開催中です。タグから「2024アドベントカレンダー」を選んでもらえれば今年分が覗けるかと思います。温泉行幸旅行から帰宅して、肌つやが最高によい龍ちゃんです。 さて、今回は頭の整理も含めて、Firestoreについて整理をしていこうと思います。Firestoreは個人開発の強い味方だと思っています。フロントエンドエンジニアからすると、手軽に認証とデータベースを追加できるという二点において神ツールです。実際に僕がプロト開発でDBを扱う場合だと、真っ先に選定されます。 今回の記事は、こんな方に読んでほしいです！ firestoreのデータ構造がいまいちつかめない Firestoreを触ったことないけど、どんなもんなん？ サブコレクションを使いだしたら混乱してきた では、失敗談も含めてお話していきたいと思います。 僕がしていた勘違いとミス まずは、僕がしていた勘違いとミスについて書いておこうと思います。 おそらく、クスっと笑ってもらえたかと思います。そんなことあるわけないですよね？やはり導入の手ごろさが癖になって、どんどんノリで開発をしていていました。そして、クエリ混沌を生み出していたわけです。 ここからは反省して改心した僕が書いています。 実際にRDBよりは、ガチガチとした設計を必要としません。特に型定義は、ソースコードで挿入する際に入ってきたデータで構造が決定されます。クエリを使用する場合では、実現したいシナリオにデータ構造を寄せておいた方が良いです。シナリオベースでデータ構造を決める作業を一つ設計として導入するべきですね。 ちょうど、今日の業務内容のメモにあったので共有しておきます。 この整理があるのとないのでは、だいぶ違います。 さて….ここまではポエムなので、そろそろ本題に入っていきます。 ここから本題：Firestoreの図解 Firestoreのイメージは、公式だと以下のイメージで図解されています。 参考 Firestore  |  Firebase Firebase 確かに端的に表現しており、良い図ですね。Firestoreを使えるようになってから見ると、この図のイメージで問題はありません。はい！「使えるようになってから」って部分が難しいところですよね。ここに落とし穴があるんです。これだけでも理解できる方向けに、各項目の説明をラフに書いておきます。 コレクション：フォルダのようなイメージで、ドキュメントを複数保存する ドキュメント：ファイルのようなイメージで、データまたはフォルダを保存する データ：key-valueで値を保存する では、図解していきます。 図解：ルートフォルダとコレクションの関係 まずは、一番トップのイメージになります。実際の画面だと、【コレクションを開始】と書かれている列ですね。 これは、【ディレクトリしか保存することができないディレクトリ】が一番イメージが近いと思います。 すべてはコレクションから始まります。すべてを飛ばしてドキュメントを作成することはできないことを押さえておきましょう。 図解：コレクション内部にあるドキュメント 次にコレクションの内部に保存するドキュメントとデータについて図解していきます。画面だとこの部分です。 先ほどの資料では、ドキュメントは一枚の紙のイラスト（もしくはGoogle Doc）で表現されていました。ここが落とし穴です。ドキュメントは、関連してサブコレクションを持つことができます。つまり、一枚のドキュメントと関連するフォルダーからなるグループ群がドキュメントとなります。 ドキュメントでは、サブコレクションとフィールド（データ）を保存することができます。フィールドでは、Key-Value型で情報を保存することができます。サブコレクションの内部では、また同一にこの世界が広がっていきます。 単一の構造で済む場合は、ドキュメントに情報を保存することで公式が出しているスタイルで済みます。ですが、サブコレクションを導入した途端に複雑な構造になってしまいます。 データの取り出し方（クエリを書く前） ドキュメントやデータの検索の方法について解説しておきます。基本的にDBが欲しい時は、データを保存したい時ですよね。（これは当たり前か） データの特定方法は、ざっくりと三通り紹介します。 単一ドキュメント：ドキュメントのIDを指定して取得 複数ドキュメント：コレクションを指定して一括取得 複数ドキュメント：コレクショングループを指定して一括取得 各内容について図解していきます。 単一ドキュメント：ドキュメントIDを指定して取得 取得するドキュメントに関する情報がすべてわかっている場合では、こちらの方法を使用して取得することができます。 単一ドキュメントの取得は、どの位置のドキュメントか特定する必要があります。一階層の場合は、コレクションIDとドキュメントIDの二つでドキュメントを取得することができます。 サブコレクション内に存在するドキュメントの場合は、大元のコレクションからすべてのパスを取得する必要があります。二階層の場合は、コレクションIDとドキュメントIDを用いて、所属するサブコレクションを特定します。サブコレクションIDとドキュメントIDを用いてドキュメントを取得することができます。 この手法では、階層が深くなるほどドキュメント取得に必要な情報が多くなります。 複数ドキュメント：コレクションを指定して一括取得 こちらは、複数ドキュメントを取得・検索するときに使用します。単一階層の場合では、コレクションIDと条件（where）を指定しない場合は、所属するドキュメントすべてを取得します。サブコレクションを対象とする倍は、コレクションIDとドキュメントID・サブコレクションIDの三つが必要になります。 ドキュメント取得には、 条件や並び替え を指定することができます。ドキュメントに含まれるデータによって検索することができます。こちらの検索条件を含めてクエリと呼んでいますが、クエリの条件に関しては、次の章で解説を入れておきます。 複数ドキュメント：コレクショングループを指定して一括取得 こちらも、複数ドキュメントを取得・検索するときに使用します。先ほどの『コレクションを指定して一括取得』とほぼ同等ですが、コレクションの指定の仕方が異なります。 コレクショングループ を指定して取得します。 こちらは、シナリオベースで理解するほうが早いです。コレクションIDは自動でIDを振る方法と自分で任意の名前を付ける方法があります。「ユーザーコレクション内にそれぞれTODOを保存しているサブコレクション」があると仮定します。先ほどの方法では、何度もクエリを叩く必要があります。取得のイメージは以下になります。 コレクショングループで、『todo』を指定します。すべてのドキュメントのサブコレクション（todo）からドキュメントを取得します。一致するコレクションIDすべてから、ドキュメント群をすべて取得します。 もし、ほかのコレクションやサブコレクションにtodoがあった場合は、そこからも情報が取得されます。そのため、コレクショングループを使用する場合は、コレクションIDを付けるのは注意して行いましょう。 クエリの制限 基本的な情報はすべて 公式リファレンス に記載があります。開発の際に詰まった内容としては、コレクションに対しては、単純にwhere句を使用することができます。ですが、コレクショングループを使用する場合は、indexを作成する必要があります。 エラーメッセージが出てきて、URLが出てきた場合はアクセスするだけでビルドしてくれます。3～10分程度待てばビルドされるのでおとなしく待ちましょう。 Firestoreでは配列をそのままデータとして保存することができます。配列に対しては、[array-contains/array-contains-any/in/not-in]（ ここです ）といったメソッドを使用することができます。 こちらのメソッドすべてに共通することですが、配列にはオブジェクトを保存することができます。検索系のメソッドの場合はオブジェクトが完全一致するなどの処理でしかできません。いい説明が思いつかないので、コードで表現してみます。 const string_array = ["A","B","C","D","E"] as string [] // Aを検索 // string_arrayには含まれる const object_array = [{label:"A", value:1},{label:"B", value:2}, {label:"C", value:3}] // {label "A"}といった検索はできない // objectの場合は、すべての情報が一致しなければいけない そのため、オブジェクト配列を使用する際は考えて実装する必要があります。 また、配列の長さに関してはクエリを発行することができません。解決策としては、 こちらの情報 が参考になります。日本語訳にすると、配列の長さを保存するKey-Valueを保存してそちらをキーにして情報を精査します。 どのように開発していくと良いか？ とりあえず必要な話は、全て図解しました。自分の失敗談を含めて、今後開発をするためにはどのような手順を踏むべきかについて書いていこうと思います。 実現したい内容をシナリオベースで言語化する 仕様が変わるときは、DBの構造自体を変更することを厭わない 色々なシナリオで失敗パターンを経験しておく 一番大事なのは、『シナリオ化』になります。詳細に言語化することが一番大切だと思います。このシナリオ化の程度は、メモレベルでも十分だと思います。コードレベルで構造を決定することもあり、走り出して作り上げることが可能です。その一方で、仕様変更に耐えることができるのか？という疑問があります。経験則ですが、勢いで作り上げたFirestoreは特殊な構造になったいると思います。後から、構造や仕様を変更しようとすると迷子になるのでメモは取っておきましょう。 次の『仕様が変わるときは、DBの構造自体を変更することも厭わない』と『いろいろなシナリオで失敗パターンを経験しておく』は関係深いと思います。Firestoreでは、できること・できないこと・できるけど実装しにくいことの三つがあります。そういったパターンを網羅することは、難しいですし、自分の実装パターンを持っておくことが大切だと思います。先ほども「作り上げることができる」とは書きましたが、これにはできるけど実装しにくいことが含まれる場合は、いっそのことDBを一から構築しなおしましょう。案外、構造を変えることですっきりするかもしれません。 終わり 最後まで読んでいただき、ありがとうございます。本記事がFirestoreの理解の一助になれば幸いです。特に個人開発やプロトタイプ開発では、Firestoreの柔軟性と使いやすさは大きな武器となります。 次回は、実際のプロジェクトでの具体的な実装例についても触れていければと思います。もし質問やご意見がありましたら、コメント欄でお待ちしています。 それでは、また次回の記事でお会いしましょう！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Firestoreの使い方を改めて図解しておく first appeared on SIOS Tech. Lab .

こんにちは。サイオステクノロジーの木村です。 サーバーのメンテナンス作業などを行う際に、サイトにアクセスしてきたユーザーに通常の画面を表示せずに「メンテナンス中画面」を表示する方法について記載します。 通常の画面表示とメンテナンス画面の表示を簡単に切り替えられるよう、maintenance.html というファイルが存在すればメンテナンス画面を表示し、すべてのアクセスに対して maintenance.html を返すようにします。 環境 Apache/2.4.62 (Rocky Linux) 手順 1. メンテナンス画面のHTMLファイルを maintenance.html.off というファイル名で作成します。 ・ maintenance.html.off <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <title>メンテナンス中</title> <style> body { text-align: center; } </style> </head> <body> <h1>ただいまメンテナンス中です。</h1> <p>しばらくお待ちください。</p> </body> </html> 2. 作成したhtmlを、 /var/www/html 配下におきます。 3. /etc/httpd/conf.d/maintenance.conf を作成し以下を記載します。 ・ maintenance.conf ErrorDocument 503 /maintenance.html <IfModule mod_rewrite.c> RewriteEngine On ## メンテナンス画面表示を除外したいIPアドレスがある場合はこちらに記載 RewriteCond %{REMOTE_ADDR} !=123.456.789.000 # メンテナンスページが存在する場合の処理 RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f RewriteCond %{REQUEST_URI} !^/maintenance\.html$ RewriteRule ^.*$ /maintenance.html [R=503,L] </IfModule> 4. SSLでアクセスする場合は、 /etc/httpd/conf.d/ssl.conf に以下の記載を追加します。 ・ ssl.conf <VirtualHost _default_:443> ・・・(省略)・・・ Include conf.d/maintenance.conf ・・・(省略)・・・ </VirtualHost> 4. 上記設定を反映させるためリロードします。 systemctl reload httpd 以上で設定は完了です。 5. メンテナンス画面を表示したいときは、ファイル名を maintenance.html に変更します。 mv /var/www/html/maintenance.html.off /var/www/html/maintenance.html 6. メンテナンス画面の表示をやめたいときは、ファイル名を maintenance.html.off に戻します。 mv /var/www/html/maintenance.html /var/www/html/maintenance.html.off ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Apache でメンテナンス中画面を表示する first appeared on SIOS Tech. Lab .

挨拶 ども！ちょっと休暇をとって温泉地に移動中の龍ちゃんです。2泊3日で温泉を堪能する予定です。 今回は、だいぶ特殊な要件：「Tailwindを純粋なCSS Styleのみに変換したい」を満たす内容でニッチすぎる内容になっています。僕はHTMLメールをTailwindから書きたいという部分から始まりました。 mailwind Tailwindで表現したHTMLをstyleに変換して出力してくれるライブラリが「 mailwind 」になります。こちらのライブラリは、HTMLファイルを解析して以下のことができます。 CSSファイル出力 Inline-CSS形式で記述されたHTML形式ファイル出力 参考 GitHub – soheilpro/mailwind: Use Tailwind CSS to design HTML emails. GitHub 環境構築 すでにHTML + Tailwindでコーディングをできる環境は整っている前提で進めていきます。もし整っていない方は、以下の記事を参考にして自分なりの環境を整えてください。 2022-10-21 Tailwind環境をシンプルに構築 :Tailwind 2022-10-25 シンプルなTailwind環境構築を効率的に改革 Browsery Sync mailwind Setup 環境のセットアップはとても簡単に完了します。 npm install mailwind こちらのコマンドだけでインストールは終了です。次に実行コマンドについて記載しています。mailwindでは、入力として二つのファイルを受け取ることができます。 入力 解説 —input-html Tailwindで記載されているHTMLファイル ※必須 —tailwind-config Tailwindの設定ファイル（デフォルトでtailiwnd.config.jsになっている） 出力としては、以下の二つになります。 出力 解説 —output-html 入力で受け取ったHTMLファイルにinline-style形式で追記されたファイル —output-css 入力で受け取ったHTMLファイルで定義されているTailwindクラスのCSSファイル 出力はどちらか一方でも、両方でも値として渡すことができます。両方渡してもあんまり意味ないですけどね。 参考のコマンドです。 # inline cssのみ mailwind --input-html public/input.html --output-html output.html # CSS ファイルのみ生成 mailwind --input-html public/input.html --output-css style.css # inline-style:html css両方作成 mailwind --input-html public/mail.html --output-html output.html --output-css style.css Example：before → after 出力の結果をサンプルとして置いています。 こちらをtailwind形式で記載したファイルが以下になります。 <div class="flex flex-row items-center justify-start gap-4 w-full p-10 flex-wrap"> <div class="inline-flex w-52 flex-col gap-2 p-2 rounded-md bg-white shadow"> <h2 class="text-lg font-bold">まっすぐ歩く</h2> <p class="text-green-500">実行中</p> </div> <div class="font-bold text-2xl">→</div> <div class="inline-flex w-52 flex-col gap-2 p-2 rounded-md bg-white shadow"> <h2 class="text-lg font-bold">右に曲がる</h2> <p class="text-red-500">実行終了</p> </div> </div> こちらをmailwindを用いてinline-style形式に変換したのが以下になります。 <div class="flex flex-row items-center justify-start gap-4 w-full p-10 flex-wrap" style="display: flex; width: 100%; flex-direction: row; flex-wrap: wrap; align-items: center; justify-content: flex-start; gap: 16px; padding: 40px;"> <div class="inline-flex w-52 flex-col gap-2 p-2 rounded-md bg-white shadow" style="display: inline-flex; width: 208px; flex-direction: column; gap: 8px; border-radius: 0.375rem; background-color: #fff; padding: 8px; --tw-shadow: 0 1px 3px 0 rgb(0 0 0 / 0.1), 0 1px 2px -1px rgb(0 0 0 / 0.1); --tw-shadow-colored: 0 1px 3px 0 var(--tw-shadow-color), 0 1px 2px -1px var(--tw-shadow-color); box-shadow: var(--tw-ring-offset-shadow, 0 0 #0000), var(--tw-ring-shadow, 0 0 #0000), var(--tw-shadow);"> <h2 class="text-lg font-bold" style="font-size: 18px; font-weight: 700;">まっすぐ歩く</h2> <p class="text-green-500" style="color: #22c55e;">実行中</p> </div> <div class="font-bold text-2xl" style="font-size: 24px; font-weight: 700;">→</div> <div class="inline-flex w-52 flex-col gap-2 p-2 rounded-md bg-white shadow" style="display: inline-flex; width: 208px; flex-direction: column; gap: 8px; border-radius: 0.375rem; background-color: #fff; padding: 8px; --tw-shadow: 0 1px 3px 0 rgb(0 0 0 / 0.1), 0 1px 2px -1px rgb(0 0 0 / 0.1); --tw-shadow-colored: 0 1px 3px 0 var(--tw-shadow-color), 0 1px 2px -1px var(--tw-shadow-color); box-shadow: var(--tw-ring-offset-shadow, 0 0 #0000), var(--tw-ring-shadow, 0 0 #0000), var(--tw-shadow);"> <h2 class="text-lg font-bold" style="font-size: 18px; font-weight: 700;">右に曲がる</h2> <p class="text-red-500" style="color: #ef4444;">実行終了</p> </div> </div> ファイルを見ていただいたらわかる通り、必要な情報がすべてHTMLに乗っています。 試したけどできなかったこと tailwind.configで記載しているGoogle Fontsの情報はロードされませんでした。ただ、定義した追加・自作のTailwindに関しては反映されていました。 どうしても使用したい場合は、HTML側に記載しておくなどの対応が必要そうです おわり ども！今回の要望はだいぶニッチだったなと我ながら思います。そんなニッチの要望も世界のどこかで需要があってライブラリが開発されているのってすごいですよね。 ちなみに僕は社内メールをTailwindを書きたかったので、今回のライブラリを発見しました。そこから発展してStremlitでHTMLでデザインをするときも利用できそうということで、次回のブログのネタにしておきます。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Tailwindをstyle属性へ変換【mailwind】 first appeared on SIOS Tech. Lab .

element. --> こんにちは、サイオステクノロジーの佐藤です。 満を持して2024年アドベントカレンダー3回目の登場です！ 今回はCosmosDBのパーティションについてご紹介します。 パーティション は、前回ご紹介したRUと同じくCosmosDBにおいて非常に重要な概念となります。 コンテナ作るときにPartitionKey設定するけどこれって何の値？ どんな値をパーティションキーに設定すればいいの？ 論理パーティションと物理パーティションキーって何？ といった方は、是非最後までご覧ください！ はじめに 今回は、CosmosDBのパーティションについて勉強したことをアウトプットしていきます。 パーティションとは何か 論理パーティションと物理パーティションの違い 分割方法はどういったものがあるか 良いパーティションキーの設定とは？ といった点について紹介していきたいと思います。 ただパーティション分割の設計ノウハウまで突っ込めるほどまだ精通できていないので あくまで概要の紹介にとどまりますが、ぜひ最後までご覧ください！ パーティションとは そもそもパーティションとはなんでしょうか？ CosmosDBにおけるパーティションについては、以下2つのものが存在します。 論理パーティション(Logical Partition) 物理パーティション(Physical Partition) これらは似て非なるものであるため、 文脈や会話の中で「パーティション」と出てきた際は、どちらを指しているかを正しく把握しておきましょう。 論理パーティション 論理パーティション(Logical Partition)は、コンテナがパーティションキーによって分割されたサブセットの単位になります。 “論理”という名がついている通り、ハードウェア的に分離されてはいません。 あくまでCosmosDB上でソフトウェア的に分離されているサブセットになります。 では パーティションキー とはなんでしょうか？ CosmosDBでコンテナを作成する際に、指定が必須の項目でもあります。 これはコンテナを論理パーティションに分割し、水平方向にスケーリングするために使われる値です。 コンテナがどのように論理パーティションに分割されるかを見ていきたいと思います。 例として、以下のようなデータベース・コンテナを考えます。 Property Name Database Restaurants Container Foods Partition Key /country そして、以下のようなアイテム群が Foods コンテナに格納されているとします。   [     {         "foodId": "001",         "name": "寿司",         "country": "日本",  //partition key         "price": "2000",         "category": "米類"     },     {         "foodId": "002",         "name": "うどん",         "country": "日本",  //partition key         "price": "500",         "category": "麺類"     },     {         "foodId": "003",         "name": "パスタ",         "country": "イタリア",  //partition key         "price": "1000",         "category": "麺類"     },     {         "foodId": "004",         "name": "餃子",         "country": "中国",  //partition key         "price": "300",         "category": "点心類"     } ] この場合、以下の図ような形で論理パーティションに分割され、その論理パーティションの中に該当アイテムが格納されます。 なお、この論理パーティションの数には制限はありませんが、ストレージ容量に関しては制限があります。 いち論理パーティションあたり20GBまでのデータしか格納することが出来ません。 そのため膨大なデータを格納する場合は、より論理パーティションを分割するために パーティションキーの値を見直す 合成パーティションキー(後述)を採用する 階層パーティションキー(後述)を採用する といった対応を検討します。 なお、一度作成した論理パーティションの内容は変更できません。 新規のパーティションキーを設定して、新たにコンテナを作り直し、データを移行する必要があります。 物理パーティション 論理パーティションと双璧をなしているのが 物理パーティション(Physical Partition) です。 ただし、CosmosDBを利用するエンジニアがこの物理パーティションの分割を考慮する必要はありません。 そこはCosmosDB側で完全に管理してくれます。 論理パーティションとの関係性を見てみたいと思います。 1つ、または複数の論理パーティションが単一の物理パーティションに割り当てられます。 逆に1つの論理パーティションが、複数の物理パーティションに割り当てられることはありません。 先程の例に照らし合わせると、以下のような感じです。 物理パーティションの容量も50GBといったように制限はありますが、これを超過しそうになった場合でも CosmosDB側で、物理パーティションを分割して論理パーティションの割り当てを入れ替えることによってこれを回避します。 インパーティションクエリとクロスパーティションクエリ 論理パーティションと物理パーティションの概要が分かったところで 適切にパーティション分割が行われることによるメリットについてお話したいと思います。 先程、論理パーティションを分割をすることで20GBのデータ許容量を超えないようにすることが可能であると述べましたが データ容量の観点の他にも、スループットの面で恩恵を受けることができます。 例えばFoodsコンテナに対して、以下のようなクエリを実行します。 select * from c where c.country = "日本" このクエリを実行した際、コンテナ全体(全ての物理パーティション)に対して検索がかかるのではなく 日本 の論理パーティション内、正確にはその論理パーティションと対応する 物理パーティションA でのみ検索が行われます。 このように検索範囲が絞られることにより検索速度も向上しますし、利用されるRU数も少なく済みます。 このように、ひとつの物理パーティション内でのみ検索が行われるものを、 インパーティションクエリ と呼びます。 一方で select * from c where c.category = "麺類" といったクエリの場合は、論理パーティションを跨いだ検索が行われます。 つまり、該当するアイテムがどこの物理パーティションに存在するかが不明であるため、**全ての物理パーティションごとに**検索が行われます。 これを クロスパーティションクエリ と呼び、インパーティションクエリに比ると検索速度が劣化します。 とはいいつつ、実際のところ完全にインパーティションクエリだけでアプリケーションを実装することは不可能に近いと思います。 CosmosDB側もクロスパーティションクエリが行われることを想定しており、このクエリを並列化し、高速化するような最適化の手段がSDKなどには提供されています。 以下のようなケースを除いて、そこまで必死に回避する問題ではないとMSのドキュメントにも書かれていました。 30,000 より多くの RU をプロビジョニングする予定 100 GB を超えるデータを格納する予定 スループットの分散 ここからが重要なポイントなのですが コンテナーに対してプロビジョニングされたスループットは、 物理パーティション間 で均等に分割されます。 例えばFoodsコンテナに4000RU/sのスループットが割当たっている場合 上記の図においては、物理パーティションA,Bそれぞれに2000RU/sのスループットが割り当たります。 そして、選択したパーティションキーによって データとアクセスが均等に分散されるようにパーティション分割が行われている事 ことが非常に重要です。 このパーティション分割が正しく行われない場合、 ホットパーティション と呼ばれる現象が発生することが懸念されます。 ホットパーティション ホットパーティションは、特定のパーティションにデータやアクセスが集中していることを指します。 例えば先程のデータベースの例で、以下のような状況だとします。 日本食がとても有名なレストラン 日本食のメニューがとても多い お客さんの大半が日本食を注文する すると、データベースの状況としては以下のようなことが起こりえます。 先程も述べたように 物理パーティションは与えられたスループットを平等に分割して利用する ひとつの論理パーティションを複数の物理パーティションに分割することはできない といった事情があるため、このひとつの物理パーティションにデータ・アクセスが集中することは避けられません。 このような状況では 物理パーティションA 1000RU/sのスループットでは処理しきれない 物理パーティションB 1000RU/sのスループットを持て余す(コストの無駄) といった状況が起こりえます。 また、ストレージの面でも同様のことが言えます。 最初に述べたように、1つの論理パーティションの最大容量は20GBです。 そのため、1つの論理パーティションにデータが集中してしまうと、すぐにデータ許容量を超えてしまいます。 そのため、各物理・論理パーティションにデータやアクセスが分散されるように、パーティション分割を行うことが非常に重要です。 なお、ホットパーティションは開発時はデータが少なくて気づかないことが多く、**本番運用の際に大量のデータが入って初めて発覚するケースも多い**ため注意が必要です。 各パーティションにおける利用率はAzureMonitorにて確認が可能です。 例えば、 PartitionKeyRUConsumption の指標を見ることで、パーティションキーあたりのRU/s使用率を確認できます。 また、 PartitionKeyStatistics の指標を見ることで、各パーティションの容量を確認することができます。 これらの値を参照しながら、適切にデータ・アクセスが分散しているかを確認しましょう。 パーティションキーの設定 適切なパーティション分割を行うために、パーティションキーの設定が重要であることが分かりました。 ここでは、パーティションキー設定に関する方法をご紹介します。 まず、大前提としてCosmosDBが顧客(アプリ)によってどのように使われるかを検討することがとても大切です。 全く同じデータを格納する場合でも、使われ方によってパーティションキーの選択は変わってきます。 例えば先程のRestaurantデータベースの例においては 読み取りのアクセスが多いのか、書き込みのアクセスが多いのか 何をフィルターとして検索することが多いのか 値段 カテゴリ 国情報 など、まずはどのようにアプリが使われるかをしっかりと把握します。 パーティションキーの設定の基本 アプリの使われ方を把握したら、次にパーティションキーの検討を始めます。 まず、パーティションキーの設定を設定するうえで、以下のことに気を付けます。 パーティションキーの値が更新されないこと Stringの型であること パーティションキーの値の種類が広範囲に広がること(=カーディナリが高いこと) 各論理パーティションに対してデータ・アクセスが均等に分割されること パーティションキーの値の長さを最大でも2KB以内とすること これらの点を踏まて、パーティションキーを設定します。 そのうえで、「アイテム要素1つだけだとうまく均等に分散させれなさそう」といった場合に 合成パーティションキー 階層パーティションキー といったパーティションキー設定の方法を検討します。 合成パーティションキー 合成パーティションキーは、複数の要素を組み合わせをキーとする方法です。 これまで扱ったデータベースを題材とすると、 "country + category" といった形の合成キーを考えます。 コンテナ作成時のPartition keyの値としては /partitionKey といったものを追加し アイテムをアップロードする際に、以下のような値を追加します。 {     "foodId": "001",     "name": "寿司",     "country": "日本",     "price": "2000",     "category": "米類",     "partitionKey":"日本-米類" //countryとcategoryを組み合わせた文字列を生成 } 他のアイテムに関しても同様に値を追加します。 {     ...     "partitionKey":"日本-麺類"     ... }, {     ...     "partitionKey":"イタリア-麺類"     ... }, {     ...     "partitionKey":"中国-点心類"     ... } これにより、論理パーティションが4つ作成されることが想定されます。 論理パーティションが3つ→4つに増えたことにより、先程起きていたホットパーティションを多少回避できそうです。 ただし、合成パーティションキーを実施することによるデメリットも発生します。 先ほどインパーティションクエリの例で挙げた以下のクエリですが select * from c where c.country = `日本` 合成パーティションキーを使用した場合は、country単体ではパーティションキーは設定していないため、クロスパーティションクエリが発生します。 また、そもそもPartitionKeyを設定するためだけに、無駄な結合字列を追加するのもあまり気持ちいいものではありません。 これらのメリット・デメリットを踏まえて合成パーティションキーの採用を検討する必要がありそうです。 階層パーティションキー 階層パーティションキー(HPK)は、階層的にパーティションキーを設定する方法です。 コンテナ作成時に Add hierarchical partition key を選択することで、3階層まで設定が可能です。 例えば、上記の例だと "country/category" といった2階層のパーティションキーを設定しています。 この時、countryのパーティションキーによって論理パーティションに分割され、 更に2階層目 category によって サブバーティション と呼ばれるものに分割されます。 こちらも先程の合成パーティションキーと同じく、データやアクセスを論理パーティションで分散できるものです。 では合成パーティションキー比べて何が違うというと、 そもそも無駄な情報( partitionKey )を追加しなくていい 上位のパーティションキーのみでの検索が可能 といったメリット点があります。 このサブセットを有効活用するようなクエリとしては以下のような形となります。 select * from c where c.country = `日本` and c.category = `麺類` この場合、サブセットパーティション単位でのクエリとなるため、インパーティションクエリとして実行が行われます。 また、以下のような上位のパーティションキーのみをフィルタに用いたクエリでも効率的に検索が行えます。 select * from c where c.country = `日本` 「以下のクエリでも効率的に検索が行えます。」と曖昧に書いたのですが、理由としてはその仕組みにあり 日本/麺類 と 日本/米類 といったサブセットがある場合、これらがそれぞれ別の物理パーティションに割り当てられる可能性があります。 つまり、 日本(category) というレベルで見た場合は、別々の物理パーティションに分かれる事があるのです。 そのため、どこの物理パーティションにアイテムが存在しているか分からず、全ての物理パーティションに対して検索がかかるのかな… と思ったのですが、実際のところはそうではないみたいです。 ここはMSのドキュメントを引用しますが、どうやらいい感じにルーティングを行ってくれるようです。 完全またはプレフィックスのサブパーティション分割されたパーティション キー パスを指定することで、完全なファンアウト クエリを効率的に回避できます。 たとえば、コンテナーに 1000 個の物理パーティションがあり、特定の TenantId 値がそのうちの 5 つにしかない場合、クエリは少数の関連する物理パーティションにのみルーティングされます。 ※ここで書かれている TenantId は上記最上位のPartitionKeyを指しており、上記の例でいうcountryと同列。 ※ファンアウトクエリ＝全ての物理パーティションごとにクエリを実行すること。 ということで、詳細までつかめていないので「効率的に検索が行えます」といった曖昧な書き方にとどめました。 このあたりしっかり分かったらまた追記修正します。 それで話は少し戻るのですが 今回、 country/category のサブパーティションの単位でストレージ20GBの制限が設けられます。 つまり、 country のレベルで見た場合、20GB以上のデータを保持することが可能になるのです。 これが単一の country をパーティションキーとした比較した場合のメリットになります。 これまでの情報をまとめると、階層パーティションキーを利用することで データ・アクセスを分散させることが出来る 上位のパーティションキーだけでも20GB以上のデータを保持できる 上位のパーティションキーだけでも効率的な検索が行える といったメリットがあることがうかがえます。 ただ、この効率の良い検索もあくまで上位パーティションキーのみが対象で select * from c where c.category = `麺類` といった、下位のパーティションキーで検索をかけた場合はクロスパーティションクエリとして扱われるので注意が必要です。 パーティションキーにアイテムIDを設定する 最後に、パーティションキーの値にアイテムID(=”/id)”を採用することについてご紹介します。 この”/id”とはCosmosDBにアイテムを追加した場合に自動で割り当てられる値です。 例えば以下のようなデータを追加した場合でも このような値が登録され、 id というGUIDのような値が割当たっています。 (もしくはidの値を自分でも設定することが可能ですが、ここでは「アイテムごとに異なる値である」という前提で話を進めます。) この値をパーティションキーとすることで、全データを全て異なる論理パーティションに分散させることができます。 分散の極みであり、ホットパーティションとは無縁ですね。 なおかつ、この id 値が分かっている場合は非常に高速で、低いRUで検索が行うことができます。 「え、そんなに何十万、何百万っていう個数の論理パーティション作っていいの…？」 と不安になる方もいるかもしれませんが、心配ありません。 MSのドキュメントにも以下のように書かれていました。 ID をパーティション キーにした場合、顧客の数だけ論理パーティションが存在し、各論理パーティションに 1 つのドキュメントしか格納されていない状態になるのでは、と不安になるかもしれません。 何百万人もの顧客がいれば、何百万個もの論理パーティションができることになります。 ただし、これはまったく問題ありません。 論理パーティションは仮想的な概念であり、持てる論理パーティション数に制限はありません。 Azure Cosmos DB により、同じ物理パーティション上に複数の論理パーティションが併置されます。 論理パーティションの数またはサイズが大きくなると、Cosmos DB により、必要に応じて新しい物理パーティションに移動されます。 参考： https://learn.microsoft.com/ja-jp/training/modules/implement-non-relational-data-model/6-choose-partition-key そのため、遠慮なく必要であれば id の値をパーティションキーとして設定しましょう。 まとめ 今回はCosmosDBのパーティションについてまとめてみました。 論理パーティションと物理パーティションの違いや、パーティションキーの設定についてなんとなく分かっていただけたのではないでしょうか？ パーティションキーの設定に関しては色々と奥が深そうなので、また触っていくうちにアウトプットしていきたいと思います。 引き続きCosmosDBの学習を続けていきたいと思うので、また読んでいただけると幸いです。 ではまた！ 参考 https://learn.microsoft.com/ja-jp/azure/cosmos-db https://learn.microsoft.com/ja-jp/training/modules/implement-non-relational-data-model/6-choose-partition-key おまけ 前回の記事でも紹介しましたが、2024年のMicrosoft Ignite でCosmosDBのベーシックな内容が紹介されていました。 Partition Keyの設定に関しても触れられていたので、是非こちらも見ていただければと思います。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 1人がこの投稿は役に立ったと言っています。 The post 【Azure】CosmosDBにおけるパーティション入門ガイド【初心者向け】 first appeared on SIOS Tech. Lab .

この記事では、複数のAIモデルを無料で簡単に比較できる便利なAI比較サイト「 天秤AI 」について、魅力と活用方法をご紹介します。 天秤AIを使うことで、各社のAIモデルを同時に利用・比較でき、どのAIが自分のニーズに最適かを手軽に見極めることができます。 天秤AIで何ができる？ 「天秤AI」は、無料で複数のAIモデルを同時に利用できるサービスです。以下の3つの特徴を持っています： 無料 （1日に利用できる制限あり） 複数のAIに同時に質問を投げて、それぞれの回答を比較することが可能 GPTやGeminiなど、異なる企業のAIモデルを一度に利用可能 みてもらったほうがわかりやすいので、早速画面をお見せします。   このように、質問を入力すると、各AIが同時に回答してくれます。   左のメニューで使用するモデルを選び、右側に追加していく形で設定します。 1つのモデルからでも利用でき、 最大で6つのAIモデルを同時に利用可能 です。 無料で利用できますが、1日あたりの利用量に上限が設けられており、利用量に応じて制限がかかります。 天秤AIの利用ケース 天秤AIは、以下のような場面で役立ちます。 AIの性能比較 : この利用法だとGPTとGeminiどっちが良いかな？というときに、さっと試すことができます。 AIの検証 : 新しいプロンプトエンジニアリングの手法を試してみる際に、1回で複数の結果が得られるので、効率的に試すことができます。このモデルだとうまくいくけど、このモデルだとダメみたいなこともちょくちょくあります。 無料で簡単に試す : 新しいAIモデルを試したいけれど費用が気になるという場合でも、各社のAIを無料で試せます。 利用制限時の代替手段 : ChatGPT-4.0を利用していたが利用制限に引っかかった場合、制限中は天秤AIで同じモデルを使うことで解決できます。 実際に使ってみる 実際に天秤AIを使ってみましょう。 天秤AIで利用可能な中で、各社の代表的なモデルである、GPT-4.0、Gemini 1.5 Pro、Claude 3.5 Sonnetを利用して、「使っていると頭が良く思われそうな語彙を教えて」と質問してみます。 拡大->   GPTは語彙を列挙すると同時に意味を簡潔に説明してくれ、端的な回答をしています。 Geminiはブログのようにタイトルから始まり、注意点を述べた後、カテゴリごとに語彙を列挙し詳細な説明を加えています。他のモデルと比べて回答量が2〜3倍あります。 Claudeは実践的な言い換え表現を教えてくれており、他のモデルとは異なり語彙の説明はありません。 このようにシンプルな質問でも、各モデルの回答に意外な差が出ることがあります。   次に、ちょっとした検証として、AIに意地悪な質問をしてみます。 「音楽バンド、ミスターイエローポテトは何人組だっけ？」   1人だけ、すごく嘘をついてくる人がいます：   「嘘はつかないで！」と加えてみます。 嘘をつかなくなりました。 こちらは以前検証してみたので、詳しくはこちらをご覧ください： chatGPTに「ハルシネーションしないで」とお願いしたら効果がある？   この、「嘘の回答をしてくるモデルに対して、嘘つかないで！というとどうなる？」という検証では、まず「嘘の回答をしてくるモデル」を探す必要がありますが、これを３つのモデルに対して一気に質問することで、効率的に検証を進めています。 このように、プロンプトの検証を複数のAIで一気に行うことで、試行回数を減らし効率的に検証を進めることができます。 天秤AIのデメリット 天秤AIでは、ClaudeのArtifactsや、最近GPTでリリースされたCanvasなどの高度な機能を利用することはできず、基本的なモデルの比較や利用に限定されています。 これらの新機能は非常に強力であり、天秤AIのシンプルな機能では物足りなく感じるかもしれません。 あくまで天秤AIは、これらの高度な機能を必要としないシンプルなモデル比較やプロンプトの試行に適したツールです   まとめ 天秤AIは、複数のAIモデルを無料で手軽に比較できる便利なツールです。 ちょっとAIの性能を比較したい、プロンプトを効率的に検証したい、そんな方におすすめです。 興味がある方はぜひチェックしてみてください！ 天秤AI ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post どのAIが最強？最適なAIモデルを探せる「天秤AI」の紹介 first appeared on SIOS Tech. Lab .

ども！寒さが本格的になってきてタイプミスが随分と増えてきている龍ちゃんです。 こちらの記事は依然執筆した、「LINEミニアプリで作るチャットゲーム」の開発の際に気を付けていたポイントについてまとめています。 2024-09-17 LINE×生成AI：チャットバトルゲームを作る！ これからLINEミニアプリを作る人の助けになったらうれしいなと考えています。 開発に関して 開発の構成としては、フロントエンドとバックエンド分割した形で開発を進めていきました。フロントエンドをReactで、バックエンドをnest.jsで構成しています。 画面は2画面で、作成したAPIとしては3つになります。APIのざっくりとした役割としては、以下のよう内容です。 対戦相手取得：データベースからランダムに一名の情報を取得 戦績取得：LINEログインしているユーザーの情報を取得 審判AIによる判定：AOAIにアクセスして戦闘描写と勝敗を返答する 開発の際に詰まったポイント・注意点 開発の際には、いろいろ詰まった点があるのですがLIFFアプリだからこそ詰まった点に注目して大きく3点に分割してみました。 リファレンスでも「 LIFFアプリ開発ガイドライン 」というページがあるので、是非ご一読ください。 トークンの取り扱い・LINE登録情報の取得 これは、セキュリティにも関係してくるので一番気にした方が良いですね。今回の構成は、バックエンド側でAPIとして処理をするのでフロントエンドで取得した情報をバックエンドに送信する必要があります。ユーザー特定のために固有のIDを取得する必要がありました。 参考 LIFFアプリを開発する リファレンスでは、以下の二パターンでユーザー情報の取得が紹介されてます。 フロントのみで扱う場合 LIFF SDKからデコード済みのIDTokenを取得する サーバーに送信して扱う場合 AccessTokenをサーバーに送信しサーバー側でトークン検証・ユーザー情報を取得する 今回はAPIを作成したので、フロント側で取得したAccessTokenをHeaderに付与してサーバー側で情報を取得する構成で実装しました。ガイドとして公開されていたのでこちらに沿って開発をしています。 参考 LIFFアプリおよびサーバーでユーザー情報を使用する フロントエンドでLINEからのアクセスか確認 LIFFアプリは、LINE内から専用のURLを開いた際に実行されます。静的アプリとしてデプロイしている場合は、普通にアクセスができますが、LIFF SDKの初期化に失敗します。こんな時に便利な関数として、 liff.isInClient(); があります。こちらは、実行環境を判定することができます。LIFFアプリ外からのアクセスの際にはアプリとは別の画面を表示して、LINEの友達登録誘導なんてこともできるかと思います。 参考 LIFF v2 APIリファレンス 動作確認 LINEを使って開発するときは、いつでも直面する問題ですね。HTTPS化したURLしか受け付けてもらえません。さすがに開発期間中に、毎回動作確認のためにデプロイはやってられないです。そこで活躍するのが、 ngrok さんですね。お手軽に手元でHTTPS化したURLを取得することができます。 終わり 今年は、様々な形態のデモを準備していました。デモも来場される方の属性によって注目を集めれたりなかったりと様々です。LINE関連のデモの場合は、若い世代の方に好評でした。これからもひっそりと開発を進めていきます。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post LINE LIFFアプリを開発する際にはまったポイント first appeared on SIOS Tech. Lab .

こんにちは、サイオステクノロジーの佐藤 陽です。 アドベントカレンダー登場2回目です。 今日はRagasのv0.2における日本語のテストセット生成方法についてご紹介します。 すぐに利用できるソースコードも載せてますので、「最新のRagas使ってテストセットを自動生成したい！」という方は是非最後までご覧ください。 はじめに 本日紹介するのは、現状最新バージョンであるv0.2のRagasを使ったテストセット生成方法です。 テストセットとは、Ragasの評価時に利用される質問と回答のペアのデータになります。 このRagasでは、与えた文章に基づいて質問(question)と回答(reference)のペアを自動で作成してくれます。 例えば「社内規約」の文章を与えた時には、その文章に基づき 質問：有給休暇は何日取れますか？ 回答：繰越すことで最大で40日まで取得可能です といったペアを生成します。 今回のケースであれば、「社内規約」をよく知る人間がテストセットを生成するのが一番間違いはないのですが 人力で膨大なテストセットを作成するのも大変なので、Ragasの機能で自動生成してもらうのも一つの手段かとは思います。 公式ドキュメントにテストセット生成に関するチュートリアルがあるのですが、 チュートリアルをそのまま行うと日本語のドキュメントを読み込んでも、英語の内容でテストセットが生成されてしまいます。 そのため本記事では、日本語でテストセットを紹介する方法をご紹介したいと思います。 なお、本記事はv0.2.6のバージョンにおける内容であり、今後変更の可能性があります。 最新の情報に関しては公式のドキュメントを参照してください。 現状の把握 v0.1の時からもテストセットの生成方法の機能は用意されていました。 ただ、v0.1から大きなリファクタリングが実施され、利用方法が異なっています。 とはいいつつ、丁寧な チュートリアル が提供されているのでその通りやれば問題なくテストセットが生成されます。 ただ、この通りに実施すると、日本語の文章を読み込ませたとしても質問と回答のペアが英語で出力されてしまいます。 この理由としては、テスト生成に利用するためのプロンプトが英語で書かれているためです。 これに対して、「多言語に対応どうやるの？」といった内容の Issue も挙がっていました。 Issueに対する実装としては既にマージ済みなのですが、ドキュメントには現状書かれていないようです。 こちらの Issue に、「TODOリストとしてドキュメントを作成する」というタスクは追記してあるので、順次対応予定のようです。 ただ、そこを一歩先取りして本ブログで紹介してしまおう！というのが本記事の目的です。 ということで、将来的には既に公式ドキュメントに記載されているかもしれませんし、もしかしたら実装方法が変更になっている可能性もあります。 まだまだRagasも変化も多い状況だと思うので、その点踏まえて読んでいただきたいと思います。 多言語対応の仕組み まず初めに多言語対応の仕組みについて紹介します。 その方法はずばり、 構築済みのプロンプトに日本語を適用する です。 そしてこの方法が「 Adapting metrics to target language 」として公式の記事にも紹介されています。 またこれはテストセット生成に限った話ではなく、 FaithfulnessやContextRecallの評価といった通常の評価フェーズの際にも利用できる仕組みです。 adapt_prompts というメソッドを利用し、既に用意されているプロンプトに対して指定した言語を適用させます。 そしてこのメソッドは PromptMixin というクラスで定義されており、このクラスは以下のように定義されています。 Mixin class for classes that have prompts. つまり、これを継承する「プロンプトを扱うようなクラス」は adapt_prompts を利用できることになります。 この仕組みを利用し、テストセットを生成するプロンプトに対して日本語を適用し、日本語のテストセットを作成していきます。 実装 チュートリアルの確認 まずは チュートリアル にあるテストセット生成の流れを確認します。 なお今回はAzure OpenAI Serviceを利用してテストセット生成を行います。 ChatとEmbeddingsのモデルをそれぞれデプロイしておいてください。 チュートリアルの内容に沿って以下のソースコードを作成しました。 なお、エンドポイントやAPIキーなどは.envファイルに格納しているため、適宜作成してください。 import os import asyncio from dotenv import load_dotenv from ragas.llms import LangchainLLMWrapper from ragas.embeddings import LangchainEmbeddingsWrapper from ragas.testset import TestsetGenerator from langchain_openai import AzureChatOpenAI, AzureOpenAIEmbeddings from langchain_community.document_loaders import DirectoryLoader #.envファイル変数読み込み load_dotenv() # 環境変数に値をセット os.environ["AZURE_OPENAI_API_KEY"] = os.getenv("AZURE_OPENAI_API_KEY") os.environ["AZURE_OPENAI_ENDPOINT"] = os.getenv("AZURE_OPENAI_ENDPOINT") os.environ["OPENAI_API_VERSION"] = os.getenv("OPENAI_API_VERSION") async def main(): # ChatModel定義     generator_llm = LangchainLLMWrapper(AzureChatOpenAI(         azure_deployment="gpt-4o-mini-deploy",         temperature=0.8,     ))     # EmbeddingsModel定義 generator_embeddings = LangchainEmbeddingsWrapper(AzureOpenAIEmbeddings(         azure_deployment="text-embedding-3-small-deploy"     )) # Generatorの生成     generator = TestsetGenerator(llm=generator_llm, embedding_model=generator_embeddings) # テストセット生成のベースとなる文章をロード     path = "Sample_Docs_Markdown/"     loader = DirectoryLoader(path, glob="**/*.md")     docs = loader.load()     # テストセット生成 testset = generator.generate_with_langchain_docs(docs, testset_size=3)     df = testset.to_pandas()     # データフレームをCSVファイルとして保存     csv_file_path = "generated_testset.csv"     df.to_csv(csv_file_path, index=False) asyncio.run(main()) 今回は読み込むドキュメントとしては、サイオステクノロジーに関する Wikipedia の内容をDocumentIntteligenceでmd化したものとします。 sios.mdというファイルでSample_Docs_Markdownの配下に保存します。 Smaple_Docs_Markdown/sios.md では上記のプログラムを実行します。 すると以下のようなテストセットが出力されました。(一部省略) なぜか、2つ目の質問だけは日本語で回答されましたが、他は見事に英語です。   user_input reference_contexts reference synthesizer_name What historical developments have shaped our current understanding of the subject? [‘1 沿革\n\n’] The historical developments that have shaped our current understanding of the subject are not detailed in the provided context. AbstractQuerySynthesizer How do the technological offerings and solutions of サイオステクノロジー compare with those of other companies in the fields of open source software, business continuity solutions, and cloud integration, particularly in relation to Linux and Gluegent Apps? [‘サイオステクノロジー株式会社は、オープンソースソフトウェアとJavaを基盤にしたシステムやソフトウェアの開発、販売、サポートを行う企業で、2017年に設立されました。主な製品には、事業継続ソリューションの「LifeKeeper」やデータ複製ソフト「DataKeeper」があります。また、Google Appsとの連携を提供するクラウドソリューションや、業務プロセスを簡素化するワークフローシステム「Gluegent Flow」なども展開しています。さらに、セキュリティソリューションやオープンソースに関するサポートも行っています。’] サイオステクノロジーは、オープンソースソフトウェアやJavaを基盤にしたシステムの開発、事業継続ソリューションの提供、Google Appsとの連携を含むクラウドソリューションを展開しており、特にLinuxやGluegent Appsに関連する技術的な提供やソリューションは、他社と比較して独自の製品群を持っています。 ComparativeAbstractQuerySynthesizer What functionalities do Gluegent Apps provide for companies using Google Workspace or Microsoft 365? [‘7 外部リンク\n\n☐目次の表示・非表’] Gluegent Apps provide functionalities such as a shared address book for searching and selecting personnel within a company, a group scheduler for visualizing schedules by department or team, and gadgets that can be embedded in corporate portal sites, all designed for companies using Google Workspace or Microsoft 365. SpecificQuerySynthesizer 2つ目の回答が日本語だったことに関しては 「サイオステクノロジー」が重要な単語であると推察され、質問文作成時に翻訳されなかった 質問文に日本語が入っているため、回答としても日本語で返された といったことではないかな、と考察しました。 ちなみに内容としてはそれなりにいい感じです。 なので、テストセット生成としては問題ないのですが、英語に精通していない人間が評価内容をチェックするのが大変です。 では、いよいよここから日本語対応していきます。 日本語化対応 先程述べた adapt_prompts を利用していきます。 こちらの プルリクエスト にて以下のサンプルコードが書かれていたのですが これだけだと全体が把握できなかったのでこれを踏まえて手探りでやっていきます。 synthesizer = AbstractQuerySynthesizer() adapted_prompts = await synthesizer.adapt_prompts("dutch", llm) synthesizer.set_prompts(**adapted_prompts) どうやら、 QuerySynthesizer というのが肝のようです。 これについては公式のドキュメントにも定義があり、シナリオを作成するための役割を持ちます。 「シナリオって何？」と思われるかと思うのですが、テストセット生成の仕組みに関しては別途記事にしたいと思うので、ここでは割愛させていただきます。 簡単に書くと、様々な質問文を生成するために必要な情報(質問の長さ、使用する情報)をまとめたものになります。 そしてこのシナリオを元に質問文(=question=Query)や回答のペアを生成します。 つまり、このQuerySynthesizerがテストセットを作成する親玉であり、ここに対して日本語を適用していきます。 なお、このQuerySynthesizerの元になっているBaseSynthesizerというクラスを見ると、 PromptMixin クラスを継承していることも確認できます。 つまり adapt_prompts のメソッドも使えることが分かりますね。 そして、この日本語を適用したQuerySynthesizerをどこで反映させるかというと テストセットを作成する generate_with_langchain_docs の引数として与えることができます。 なのでステップとしては QuerySynthesizerに対して日本語を適用(adapt_prompts) 日本語が適用されたQuerySynthesizerを利用してテストセット生成 といった感じです。 流れが分かったところで早速これらを反映したソースコードを見てみます。 import os import asyncio from dotenv import load_dotenv from ragas.llms import LangchainLLMWrapper from ragas.embeddings import LangchainEmbeddingsWrapper from ragas.testset import TestsetGenerator from langchain_openai import AzureChatOpenAI, AzureOpenAIEmbeddings from langchain_community.document_loaders import DirectoryLoader from ragas.testset.synthesizers import AbstractQuerySynthesizer load_dotenv() os.environ["AZURE_OPENAI_API_KEY"] = os.getenv("AZURE_OPENAI_API_KEY") os.environ["AZURE_OPENAI_ENDPOINT"] = os.getenv("AZURE_OPENAI_ENDPOINT") os.environ["OPENAI_API_VERSION"] = os.getenv("OPENAI_API_VERSION") async def main():     generator_llm = LangchainLLMWrapper(AzureChatOpenAI(         azure_deployment="gpt-4o-mini-deploy",         temperature=0.8,     ))     generator_embeddings = LangchainEmbeddingsWrapper(AzureOpenAIEmbeddings(         azure_deployment="text-embedding-3-small-deploy"     ))     generator = TestsetGenerator(llm=generator_llm, embedding_model=generator_embeddings)     path = "Sample_Docs_Markdown/"     loader = DirectoryLoader(path, glob="**/*.md")     docs = loader.load()     #Synthesizerのインスタンスを生成     synthesizer = AbstractQuerySynthesizer(llm=generator_llm)     #シンセサイザーのプロンプトに日本語を適用     adapted_prompts = await synthesizer.adapt_prompts("japanese", generator_llm)     #プロンプトをセット     synthesizer.set_prompts(**adapted_prompts)     #generate_with_langchain_docsに引き渡すためのデータ整備     query_distribution = [         (synthesizer, 1.0) #1.0は割合を表し、今回はこのSynthesizerを100%利用することを表す。他のSynthesizerと組み合わせる事も可能。     ]   # テストセット生成     testaset = generator.generate_with_langchain_docs(docs, testset_size=3, query_distribution=query_distribution) #query_distributionを引数としてあたえる       df = testset.to_pandas()     # データフレームをCSVファイルとして保存     csv_file_path = "generated_testset.csv"     df.to_csv(csv_file_path, index=False) asyncio.run(main()) このプログラムを実行すると以下の結果が得られました。 全ての質問および回答が日本語で生成されている ことが分かります。 user_input reference_contexts reference synthesizer_name 沿革の重要性は何ですか？ [‘1 沿革\n\n’] 沿革の重要性は、歴史的な背景や発展の過程を理解することで、現在の状況や未来の方向性を把握する手助けとなることです。 AbstractQuerySynthesizer 企業名の由来はどう企業のアイデンティティや価値反映するの？ [‘2 社名の由来\n\n’] 企業名の由来は、企業のアイデンティティや価値を反映する重要な要素です。 AbstractQuerySynthesizer 主な製品・サービスはどのように相互に関連し、ビジネス戦略に寄与するのか？ [‘3 主な製品・サービス\n\n’] 主な製品・サービスの相互関連性とビジネス戦略への寄与についての具体的な情報は提供されていません。 AbstractQuerySynthesizer なお、今回はPRのusageを例にAbstractQuerySynthesizerを採用したため非常に抽象的なテストセットとなりました。 もちろん他のSynthesizerを利用しても問題ありません。 試しに ComparativeAbstractQuerySynthesizer を使うため、以下の部分の書き換えを行います。 synthesizer = ComparativeAbstractQuerySynthesizer(llm=generator_llm) # 対象のSynthesizerを変更 adapted_prompts = await synthesizer.adapt_prompts("japanese", generator_llm) synthesizer.set_prompts(**adapted_prompts) すると以下のような結果が得られ、回答内容がガラッと変わることも分かります。 user_input reference_contexts reference synthesizer_name サイオステクノロジー オープンソースソフトウェア 事業継続ソリューション Linux クラウドソリューション 技術 特性 機能 比較 評価 レポート [‘サイオステクノロジー株式会社は、オープンソースソフトウェアとJavaを基盤にしたシステムやソフトウェアの設計、開発、販売、サポートを行う企業で、2017年に設立されました。主な製品には、事業継続ソリューションの「LifeKeeper」やデータ複製ソフト「DataKeeper」があります。また、Google Appsとの連携を提供するクラウドソリューションや、業務プロセスを簡素化するワークフローシステム「Gluegent Flow」なども展開しています。さらに、オープンソースに関するサポートやトレーニングも行っており、セキュリティソリューションとして「i-FILTER」や「m-FILTER」も提供しています。’] サイオステクノロジー株式会社は、オープンソースソフトウェアを基盤にした事業継続ソリューションやクラウドソリューションを提供しており、主な製品には「LifeKeeper」や「DataKeeper」があります。 ComparativeAbstractQuerySynthesizer サイオスのオープンソースソフトウェアと事業継続ソリューションはどう違うの？ [‘サイオステクノロジー株式会社は、オープンソースソフトウェアとJavaを基盤にしたシステムやソフトウェアの設計、開発、販売、サポートを行う企業で、2017年に設立されました。主な製品には、事業継続ソリューションの「LifeKeeper」やデータ複製ソフト「DataKeeper」があります。また、Google Appsとの連携を提供するクラウドソリューションや、業務プロセスを簡素化するワークフローシステム「Gluegent Flow」なども展開しています。さらに、オープンソースに関するサポートやトレーニングも行っており、セキュリティソリューションとして「i-FILTER」や「m-FILTER」も提供しています。’] サイオスのオープンソースソフトウェアは、主にソフトウェアの設計、開発、販売、サポートを行うものであり、事業継続ソリューションは「LifeKeeper」などの特定の製品を指します。 ComparativeAbstractQuerySynthesizer サイオステクノロジーの事業継続ソリューションオープンソースソフトウェアクラウドソリューション他のビジネスソリューション比較利点特長は？ [‘サイオステクノロジー株式会社は、オープンソースソフトウェアとJavaを基盤にしたシステムやソフトウェアの設計、開発、販売、サポートを行う企業で、2017年に設立されました。主な製品には、事業継続ソリューションの「LifeKeeper」やデータ複製ソフト「DataKeeper」があります。また、Google Appsとの連携を提供するクラウドソリューションや、業務プロセスを簡素化するワークフローシステム「Gluegent Flow」なども展開しています。さらに、オープンソースに関するサポートやトレーニングも行っており、セキュリティソリューションとして「i-FILTER」や「m-FILTER」も提供しています。’] サイオステクノロジーの事業継続ソリューション「LifeKeeper」やデータ複製ソフト「DataKeeper」、クラウドソリューション、業務プロセスを簡素化するワークフローシステム「Gluegent Flow」などは、オープンソースソフトウェアを基盤にした利点や特長を持っています。 ComparativeAbstractQuerySynthesizer ちなみにデフォルトだと query_distribution の値としては (AbstractQuerySynthesizer(llm=llm), 0.25), #25% (ComparativeAbstractQuerySynthesizer(llm=llm), 0.25), #25% (SpecificQuerySynthesizer(llm=llm), 0.5), #50% という割合となっています。 このあたりも、どういった質問事項を作成したいかに合わせて設計していきたいところです。 まとめ 今回はRagas v0.2における日本語のデータセット生成の方法を紹介しました。 近いうちにドキュメントも整備されるとのことですが、一足お先に紹介してみました。 もしかしたら、公式のドキュメントでの起債が紹介した方法と全然違うかもしれませんが、その際は改めて修正したいと思います。 ではまた！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【Ragas】日本語テストセットの生成方法のご紹介【v0.2】 first appeared on SIOS Tech. Lab .

伊藤です。 今回は、Shibboleth IdPの属性配信同意情報をデータベースに格納する方法を紹介します。 端末に属性配信同意情報を保存した場合は、異なる端末でログインする際に再度同意が必要になりますが、属性配信同意情報をサーバに保存することで、異なる端末でログインした場合でも同意が不要になります。 Shibboleth IdPの構築 学認（以下のサイト）が提供する手順にしたがいShibboleth IdPを構築します。構築の詳細については、割愛します。 https://meatwiki.nii.ac.jp/confluence/display/GakuNinShibInstall/Home データベースのインストール データベース(MariaDB)のインストール・起動と設定を実施します。 # dnf install mariadb mariadb-server # systemctl enable mariadb # systemctl start mariadb # mysql_secure_installation <略> Enter current password for root (enter for none): ← そのままEnterを入力 OK, successfully used password, moving on... <略> Change the root password? [Y/n] ← Yを入力 New password: rootpassword ← rootパスワードを設定 Re-enter new password: rootpassword Password updated successfully! Reloading privilege tables.. ... Success! <略> Remove anonymous users? [Y/n] ← そのままEnterを入力 ... Success! <略> Disallow root login remotely? [Y/n] ← そのままEnterを入力 ... Success! <略> Remove test database and access to it? [Y/n] ← そのままEnterを入力 - Dropping test database... ... Success! - Removing privileges on test database... ... Success! <略> Reload privilege tables now? [Y/n] ← そのままEnterを入力 ... Success! <略> Thanks for using MariaDB! データベースにテーブルを作成 MariaDB上にデータベース shibboleth を作成し、テーブル StorageRecords を追加します。 # mysql -u root -p Enter password: rootpassword ← 設定したrootパスワードを入力 MariaDB [(none)]> CREATE DATABASE shibboleth; MariaDB [(none)]> CONNECT shibboleth MariaDB [shibboleth]> CREATE TABLE StorageRecords ( context varchar(255) NOT NULL, id varchar(255) NOT NULL, expires bigint DEFAULT NULL, value text NOT NULL, version bigint NOT NULL, PRIMARY KEY (context, id) ); ※ここで、context列と id列は、大文字と小文字を区別して処理および比較されていることを確認する必要があります。今回は照合順序にutf8mb4_binを設定します。 MariaDB [(none)]> ALTER TABLE StorageRecords COLLATE 'utf8mb4_bin'; テーブルにアクセスするためのデータベースユーザ(shibbolethuser)を新規作成します。パスワードを databasepassword の部分に設定します。ユーザとパスワードは、後述のデータベース接続設定で使用します。 MariaDB [shibboleth]> CREATE USER 'shibbolethuser'@'localhost' IDENTIFIED BY ' databasepassword '; MariaDB [shibboleth]> GRANT INSERT, SELECT, UPDATE, DELETE ON shibboleth.* TO 'shibbolethuser'@'localhost'; MariaDB [shibboleth]> FLUSH PRIVILEGES; MariaDB [shibboleth]> quit JDBCプラグインのインストール JDBCプラグインをインストールします。 # /opt/shibboleth-idp/bin/plugin.sh -I net.shibboleth.plugin.storage.jdbc JDBCドライバーをインストール JDBCドライバー(mysql-connector-javaパッケージ)をインストールします。 ダウンロードページは以下です。今回はmysql-connector-j-9.0.0をインストールします。 https://dev.mysql.com/downloads/connector/j/   # curl -O https://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-j-9.0.0.tar.gz # tar zxv -C /usr/share/java/ -f mysql-connector-j-9.0.0.tar.gz 以降はJARファイルが /usr/share/java/mysql-connector-j-9.0.0/mysql-connector-java.jar にインストールされていることを想定します。 edit-webapp/WEB-INF/lib/ にシンボリックリンクを作成したあとビルドスクリプトを実行しidp.warを再生成します。 # ln -s /usr/share/java/mysql-connector-j-9.0.0/mysql-connector-java.jar /opt/shibboleth-idp/edit-webapp/WEB-INF/lib/ # /opt/shibboleth-idp/bin/build.sh Installation Directory: [/opt/shibboleth-idp] [Enter]　←入力なし Rebuilding /opt/shibboleth-idp/war/idp.war ... ...done BUILD SUCCESSFUL Total time: 3 seconds ※JDBCドライバーは以下のコマンドでインストールを実施し、シンボリックリンクを作成することも可能です。 # dnf install mariadb-java-client # ln -s /usr/lib/java/mariadb-java-client.jar /opt/shibboleth-idp/edit-webapp/WEB-INF/lib/ データベース接続設定 /opt/shibboleth-idp/conf/global.xml を設定します。 <bean id="mydataSource" class="org.apache.commons.dbcp2.BasicDataSource" destroy-method="close" lazy-init="true" p:driverClassName="com.mysql.cj.jdbc.Driver" p:url="jdbc:mysql://localhost:3306/shibboleth" p:username="shibbolethuser" p:retryableErrors="4001, 4002" p:password=" databasepassword " 　　　/> <bean id="JDBCStorageService" parent="shibboleth.JDBCStorageService" p:dataSource-ref="mydataSource" p:transactionIsolation="4" p:retryableErrors="40001" /> ※driverClassNameはJDBCドライバのバージョンが8以降の場合はcom.mysql.cj.jdbc.Driver、以前のバージョンの場合はcom.mysql.jdbc.Driverを指定します。また、接続プールを提供するデータソースであるCommons DBCP 2 ライブラリはデフォルトで IdP に含まれています。 IdPの設定 idp.propertiesのStorageServiceで、データベース接続設定のbean idを指定します。 idp.session.StorageService = JDBCStorageService jettyを再起動します。 # systemctl restart jetty まとめ Shibboleth IdPの属性配信同意情報をデータベースに格納する方法をまとめました。何か少しでも参考になれば幸いです。 参考 https://meatwiki.nii.ac.jp/confluence/display/GakuNinShibInstall/Home https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/2989096970/JDBCStorageService   ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Shibboleth IdPの属性配信同意情報をデータベースに格納する first appeared on SIOS Tech. Lab .

PS/SLの佐々木です。 2024年9月にHyperledger FabricのメジャーアップデートがありVersion3がリリースされました。 今回はリリースノートからHyperledger Fabric V3で新しくどのような機能か登場したのか紹介したいと思います。 Hyperlerger Fabric V3 新機能紹介 1. Byzantine Fault Tolerant (BFT) Ordering Service 概要 BFTとは？ BFTは、単なるクラッシュ障害（Crash Fault Tolerance, CFT）に留まらず、一部のノードが悪意を持った行動をしてもシステム全体が正常に機能することを保証する仕組みです。 悪意あるノードやハッキングによる障害に強い信頼性を提供します。 背景 Fabric v1.4.1 以降、Raft ベースの CFT が主流。 Fabric v3 で初めて SmartBFT ライブラリを用いた BFT コンセンサスが導入される。 分散システムにおける真の非中央集権性 を実現するために設計されている。 利用条件 Channel Capability V3_0 を有効にする必要があります。 従来の CFT (Crash Fault Tolerance) Ordering Service 実装 : Fabric v1.4.1 以降、Raft プロトコルが採用されており、これは CFT（クラッシュ障害耐性）のみを提供。 動作原理 : ノードがクラッシュ（停止）した場合でも耐性あり。 ただし、悪意ある行動（データ改ざんや不正なリーダー選出）には耐えられない。 制約 : Raft は分散ノード間の信頼性が前提であり、ノード運営者が「信頼できる」ことを前提としている。 新しい BFT Ordering Service 実装 : SmartBFT ライブラリを活用。 動作原理 : 最大でノードの 1/3 未満が悪意ある行動をしてもシステムが正常に動作。 各ノードが異なる主体によって運営されている場合でも、完全な分散と信頼性を実現可能。 利点 開発者視点 高い耐障害性 : システムが最大でノードの 1/3 未満の悪意ある行動や障害に耐えられる。 柔軟性 : 信頼できない運営者（ノード間の異種運営）を含むシステムを構築可能。 実験的試行 : テストネットワークで簡単に試すことができ、初期設定もチュートリアルが整備されている。 ユーザー視点 データの安全性 : ネットワーク上の悪意あるノードや妨害行動がシステム全体の整合性を崩さない。 信頼性の向上 : ノード運営者が分散化され、特定の主体に依存しない。 比較まとめ 特徴 CFT (Raft) BFT (SmartBFT) 耐障害性 クラッシュ障害に耐える クラッシュ＋悪意あるノードの行動にも耐える 運営ノード間の信頼性 信頼が前提 信頼が不要、最大1/3までの不正行為を許容 適用ユースケース 信頼された環境（例: 同一企業内） 信頼できない環境（例: 複数企業間の連携） 2. Ed25519 暗号アルゴリズムのサポート 概要 Ed25519とは？ Ed25519 は、従来の楕円曲線暗号（ECDSA）よりも高速かつ安全なデジタル署名アルゴリズム。 Fabric の MSP（Membership Service Provider）機能で、署名や検証に利用可能になりました。 利用条件 Channel Capability V3_0 を有効にする必要があります。 従来の ECDSA（楕円曲線デジタル署名アルゴリズム） 性能 : トランザクション署名と検証で利用。 パフォーマンスは十分だが、Ed25519 と比較すると若干の処理遅延がある。 セキュリティ : 楕円曲線暗号は安全だが、Ed25519 と比べると一部の最新攻撃に対する耐性がやや劣る可能性が指摘されている。 新しい Ed25519 性能 : ECDSA に比べて署名・検証が高速。 トランザクション処理のスループット向上が期待できる。 セキュリティ : より新しいアルゴリズムであり、高度な攻撃に対しても強い耐性を持つ。 鍵サイズが短く、署名もコンパクト。 利点 開発者視点 高速性 : 署名や検証が効率化され、大規模なトランザクション処理においてパフォーマンス向上。 セキュリティ向上 : より強力な署名アルゴリズムで、攻撃に対する耐性が強化。 ユーザー視点 トランザクション処理速度の向上 : Ed25519 を採用することで取引の処理速度が改善され、ユーザー体験が向上。 長期的なセキュリティ対応 : 将来の暗号技術的脅威に対する準備。 比較まとめ 特徴 ECDSA Ed25519 署名・検証速度 標準的 高速 鍵サイズ やや大きい 小さい セキュリティ 十分安全 最新の脅威に対するより強い耐性 適用場面 既存システムとの互換性を重視 パフォーマンスと将来的なセキュリティを重視 3. 追加の改善点 全ての承認済みチェーンコードのクエリ 新コマンド : peer lifecycle chaincode queryapproved チャネル名を指定するだけで、そのチャネルに承認された全チェーンコードを取得可能。 利点 開発者視点 : 承認済みチェーンコードの管理が簡素化され、ネットワークのデバッグや監視がしやすくなる。 ユーザー視点 : 安全なチェーンコード管理による運用の信頼性向上。 変更点 peer.gossip.pvtData.transientstoreMaxBlockRetention のデフォルト値変更 変更点 : 保持ブロック数が 1000 → 20000 に増加。 目的 : 未コミットのプライベートデータをトランジェントストアに長期間保持し、コミット遅延に対する耐性を向上。 Proposal のタイムスタンプ検証 新機能 : TimeWindowCheck フィルターが追加され、提案リクエストのタイムスタンプをピア時間と比較して検証。 目的 : 不正確なタイムスタンプの提案が承認されるリスクを軽減。 peer.deliveryclient.blockGossipEnabled のデフォルト値が false に変更 背景 : Gossip を介したブロック配信が非推奨に。将来的に削除される可能性があり、デフォルトで無効化。 推奨設定 : ピアはオーダリングサービスノードから直接ブロックを受信する構成を採用。 削除機能 システムチャネルのサポート削除 概要 : システムチャネルが削除され、チャンネル作成は Channel Participation API 経由に移行。 利点 : プライバシー、スケーラビリティ、運用性の向上。 Solo および Kafka コンセンサスの削除 概要 : Solo はテスト用として設計されており、Kafka は Raft の導入以降非推奨だった。Fabric v3.0 では完全に削除。 対応 : Raft への移行が必要。 レガシーチェーンコードライフサイクルの削除 概要 : Fabric v1.x のチェーンコードライフサイクルは削除され、v2.x の新しいライフサイクルに統一。 対応 : 全チェーンコードを再デプロイし、チャネルアプリケーション機能を V2_0 または V2_5 に設定する必要あり。 非推奨機能 Gossip によるブロック配信 非推奨理由 : Gossip は複雑さと非効率性のため、オーダリングサービスノードから直接ブロックを受け取る構成が推奨される。 今後の変更 : 将来のリリースで削除される可能性が高い。 まとめ Hyperledger Fabric v3 の新機能は、分散型ネットワークの安全性、性能、柔軟性を向上させるために設計されています。 BFT オーダリングサービスは、より信頼性の高い分散システムを構築したい組織にとって理想的な選択肢です。 Ed25519 のサポートは、高速かつ安全な取引処理を可能にします。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Hyperleger Fabric v3.0の解説！ first appeared on SIOS Tech. Lab .

こんにちは、サイオステクノロジー 佐藤 陽です。 今回はSIOSのアドベントカレンダーの記念すべき1日目の記事です。 今年のアドベントカレンダーのテーマは「サイオス社員が今年一年で新たに学んだ技術」です！ そして私は絶賛学習中のAzure CosmosDBについて紹介していきたいと思います。 偉そうに書いていきますが、自分自身も入門したてなので、もし誤ってる点あったらコメントで指摘いただけると幸いです。 はじめに 冒頭でも述べましたが、Azure CosmosDBについて書いていきたいと思います。 私自身、ほとんどRDBMSしか触ったことがなく、NoSQLに関してはまったくの素人です。 「なんかJSONのままデータ保管しておけるんでしょ？」くらいの理解です。 ただ、先日のMicrosoft IgniteでもCosmosDBでハイブリット検索が行えるようになったという発表があり、生成AI関連でもCosmosDBの活用が注目されています。 それに、そもそもアプリケーションのDBとしてNoSQLはよく選択肢として挙がる部分なので、知っておかなくては…という思いから学習を始めました。 というところで、今回は基礎の基礎というところで、CosmosDBにおいて重要な概念である RU(Request Unit) について超入門していきたいと思います。 RUとは？ スループット(RU/s)の制限 RUと料金体系 など基本的なところを抑えていこうと思うのでぜひ最後までご覧ください。 RUとは RUはRequest Unitの略称であり、CosmosDBにおいては非常に重要な指標です。 CosmosDBのデータベースの操作を行うにあたってはCPU, メモリ, IOPSなどの様々システムリソースが必要になりますが それらが全て抽象化され、RUというメトリクスひとつに集約化されています。 そして、このRUの単位はスループット(RU/s)や利用料金にもかかわってきます。 つまり、ユーザーはRUだけを考えればいいという非常にシンプルな仕組みとなっています。 では「1RUで出来る操作はどのくらいか？」なんですが、公式ドキュメントには以下のように記載がありました。 1RU = 1 KB 項目の読み取り 5RU = 1 KB 項目の書き込み これをベースとして膨大なデータ量の読み取りを行ったり、複雑なクエリを実行することでRUが増加していくことになります。 RUを計算する上で影響する要素としては以下のようなものがあります。 アイテムのサイズ アイテムのインデックス付け アイテム プロパティの数 インデックス付きプロパティ データの一貫性 読み取りの種類 クエリのパターン スクリプトの使用 なお、また別の記事でも触れたいと思いますが、 CosmosDBのコンテナ設計を優れたものにすることで、同じデータの取り出しでも必要となるRUを小さくすることが可能です。 そのため、データモデリングやパーティションキーの設定が検索性能やコストにも直結します。 RUとCosmosDBの設定項目 では実際にCosmosDBのリソースを作成・利用していくうえで、このRUがどのように関わっていくかを見ていきたいと思います。 リソース作成画面をみてみます。 今回のポイントとしては、以下2点です。 容量モード 合計アカウント スループットを制限する なお、これから色々検証の方していきますが、Global distributionの設定に関して無効 / 無効で設定したうえで検証の方進めていきます。 マルチリージョンにすると、プロビジョニングされるRU数が2倍になったりするのでその点注意です。 容量モード CosmosDBをデプロイする際、容量モードというプロパティが存在しています。 選択肢としては2つ存在しています。 プロビジョニングされたスループット Serverless プロビジョニングされたスループット 「プロビジョニングされたスループット」に関しては、事前に使用可能な 1秒あたりのRU(=RU/s=スループット) を設定する方法になります。 例えば1000RU/sと設定した場合は、1秒間に1000回のみ「1 KB 項目のポイント読み取り」を行えるといった形になります。 なお、この設定したRU/sの値を超えてしまった場合はCosmosDBから429のエラーが返されます。 ただしCosmosDB SDKを利用している場合は、自動で再送処理の方が行われるようです。 また、このプロビジョニングされたスループットについては更に2つのプロパティを持ちます。 Manual Auto Scale Manual 「Manual」は完全にRU/sを決め打ちするような設定になります。 例えばスループットを 1000 RU/s と設定した場合は、常にRU/sは1000に固定されます。 もちろんAzure Portal上などからこの値を手動で変更することは可能ですが、アプリの使用量などによって動的に変化することはありません。 AutoScale 「Auto Scale」は設定した範囲内で、アプリの使用量に応じてスループットが変動する設定となります。 例えば上限のスループットを 1000 RU/sとした場合、以下のレンジの間でスループットは変動します。 100 RU/s ~ 1000 RU/s なお、この下限の値は上限のスループットの1/10の値となっています。 スループット制限のスコープ このスループットを制限する対象ですが アカウント データベース コンテナ それぞれで設定することが可能です。 アカウント CosmosDBアカウント全体へのスループット制限については、Cost Managementブレードから確認できます。 現在、1000RU/sとして設定されており、このアカウント全体で1000RU/sまでのスループットをプロビジョニングすることが可能となります。 この後話していくなかで、データベースやコンテナに対してそれぞれスループットを割り当てますが、それらの合計がここで設定した値以下となる必要があります。 なお、選択肢を見ていただいても分かるように「制限無し」という設定も可能で この場合は上限無くスループットを割り当てることが可能となります。 データベース まずデータベースのスコープを確認します。 まず、サンプルのデータベースを作成していきましょう。 データエクスプローラからコンテナの作成を行います。 まだデータベースが存在していないので、データベースから作成していきます。 今回は restaurant_db というDBを作ることにします。 そして、 Share throughput across containers にチェックボックスを入れます。 このチェックボックスを入れることで、このデータベースに含まれるコンテナ群でスループット量を共有するようになります。 そしてスループットの設定として、先程述べたAuto scaleからManualかを選択し、RU/sの値を設定します。 今回はAuto scaleを選択しており、値としては1000 RU/sを設定しました。 この時、先程紹介したようなレンジでRU/sが設定されていることが読み取れます。 ちなみにここで2000 RU/sを設定しようとすると怒られます。 これは、先ほどアカウント全体のスループットを1000RU/sに制限したためです。 そのため今回はデータベースのMAX RU/sの値を1000RU/sのままにして進めます。 続いてコンテナ(food_container)も作成していきます。 作成完了後、restaurant_dbに更にコンテナ(drink_container)を1つ追加します。 これでrestaurantというデータベースに対して、foodとdrinkという2つのコンテナが作成できました。 この状態でAzurePortalのCosmosDBのリソースから、Cost Managementのメニューを確認します。 この内容から以下のことが読み取れます。 restaurantのデータベースには最大1000RU/sのスループットが割り当てられている foodとdrinkのコンテナでこの1000RU/sを共有している イメージとしてはこんな感じです。 これがデータベースをスコープとしたスループットの制限となります。 コンテナ 次にコンテナをスコープとしたスループットの制限を確認します。 まず、事前準備としてCosmos DBアカウント全体のスループット許容量を増やしておきます。 ひとまず4000RU/s位にしておけば大丈夫です。 そして、新規にデータベースとコンテナを作成していきます。 この時のポイントとしては** Share throughput across containers にチェックボックスを入れません。** そして、コンテナ(employee)に対してスループットの設定を行います。 作成が完了したら、もう一つcompanyのデータベースに対してコンテナ(department)を追加しておきます。 2つのコンテナの作成が完了したら、Cost Managementを見てみましょう。 ここからから以下のことが読み取れます。 companyが持つコンテナそれぞれに対して1000RU/sが割り当てられている companyのデータベースとしては最大スループットが2000RU/sである イメージとしてはこんな感じです。 このように、最大スループットに関してはデータベースに対しても割り当てられますし、コンテナに対しても割り当てられます。 データベースとコンテナ混合 これまでデータベースとコンテナそれぞれにスループットを割り当てる方法をご紹介しました。 これに加えて、データベースに対して割り当てつつ、さらにコンテナに対してもスループットを割り当てることも可能です。 実際やってみましょう。 先程作成した restaurant のデータベースにコンテナを追加します。 そして、 Provision dedicated throughput for this container にチェックボックスを入れ、コンテナに対してスループットの設定を行います。 ではCostManagementを見てみましょう。 以下の内容が読み取れます。 restaurantのデータベースとしては最大スループットが2000 RU/sである dessertコンテナに対してだけ1000RU/sが割り当てられているである。 イメージとしてはこんな感じです。 この時気になることとしては、 「restaurantのデータベースには1000 RU/sが割り当てられてるんだし、そのデータベースに含まれるdessertのコンテナにもスループットは割り当てられる？」 といった点かと思います。 結論から言うと、そういった割り当ては行われず、 dessert のコンテナが利用できるのは1000RU/sまでとなります。 これは公式のドキュメントにも記載がありました。 参照： データベースとコンテナーでスループットを設定する 以上の内容から、プロビジョニングされたスループットの容量モードを選択した場合は 「どのスコープに対して」「どれだけのスループットを割り当てるべきか」が設計時のポイントとなりそうです。 スループットの変更 一度設定したスループットに関しても簡単に変更できます。 データエクスプローラの Scale という項目を選ぶと、AutoscaleかManualかの選択や、その設定における値も変更可能です。 アプリの利用状況などに合わせて柔軟に変更しましょう Serverless 「Serverless」に関しては、事前に使用するRU/sを設定しません。 使用量に伴って自動でスケーリングされ、最大のスループットとしては 20,000 RU/sまで増加します。 つまり、サーバーレスを利用する場合は、これまで プロビジョニングされたスループット で述べてきたようなスループットの割り当てを考慮する必要がありません。 全てCosmosDB側で自動で行ってくれます。らくちんです。 そして料金体系に関しては、利用したRUの量に依存します。 つまり何RUを利用したかによって、料金が従量課金制のように増えていきます。 ただこの時、 プロビジョニングされたスループット と Serverless で同じ量のRUを利用した場合は、Serverlessの方が使用料は高くなる傾向です。 (プロビジョニングされたスループットの設定値が適切である前提) とはいいつつ、スループットを正確に見定めるのは難しいですし、アプリの新規開発時やアプリの利用量の予測が困難な場合はひとまずServerlessを選択するのが良いかと思います。 RUの計算 自分の作ってるアプリがどれだけRUを使うか分からない！！といった方も多いかと思います。 これについては以下2つの方法が用意されています。 実測で計算する 計算ツールによる予想 実測での計算 こちらは実際にクエリを実行して、その実行に対するRUを確認する方法です。 まず、先程作成した food_container にアイテムを1つ追加します。 このコンテナー対して、データエクスプローラから以下のクエリを実行します。 SELECT * FROM c すると、結果が得られると思うのですが、 Query Stats の Request Charge の値を確認します。 これが今回のクエリ実行にかかったRUの数です。 このように実際にクエリを実行してみて、どの程度のRU数になるかを実際確認してみましょう。 計算ツールによる予測 Azureには Capacity Calculator といった計算ツールが用意されており、これを利用することでおおよそのRU数を見積もることが可能です。 料金体系 CosmosDBの利用料金は主にRUとストレージ容量によって決まります。 プロビジョニングされたスループットの場合であれば、設定したRU/sに応じて時間単位で課金が行われます。 Serverlessの場合であれば、先程述べたように、利用したRU数とストレージ容量に応じて課金が行われます。 まとめ 今回は、CosmosDBを利用するうえで重要な指標であるRequest Unitについてご紹介しました。 メモリや、CPUなどのシステムリソースを抽象化した値であり、利用する側からしたらRUのみを考えればいいので非常にシンプルですね。 ただ、プロビジョニングされたスループットの設定においてはどのスコープに対して、どれだけの値を設定するかをしっかりと考える必要があります。 性能や価格などを考えるうえで肝となる指標であるため、しっかり理解していきたいところです。 まだまだCosmosDB深掘りしていきたいと思うので次もぜひ読んでいただければと思います。 ではまた！ おまけ 2024年のMicrosoft Ignite でCosmosDBのベーシックな内容が紹介されていました。 RUとは？といった部分も紹介されていたので、是非こちらも見ていただければと思います。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【Azure】CosmosDBにおけるRU入門ガイド【初心者向け】 first appeared on SIOS Tech. Lab .

OpenShift Pipelines (Tekton) は、OpenShift 上で CI/CD パイプラインを構築するためのツールです。開発者としては、パイプラインのエラーや失敗が発生したら困るので、リアルタイムで知りたいと思います。そこで、 Tekton Catalog を参考にしてエラー通知を Slack に送信する仕組みを構築してみました。 前提条件 OpenShift 4 クラスターが構築済みであること OpenShift Pipelines Operator がインストールされていること oc CLI がインストール済みであること OpenShift Pipelines でパイプラインが構築済みであること パイプラインの構築については 以前の記事 を参考 Slack に通知を送信するワークスペース、チャンネルが用意されていること CloudEvents について CloudEvents は、イベントデータの標準化を目的とした CNCF のプロジェクトです。OpenShift Pipelines は CloudEvents をサポートしており、パイプラインの状態をイベントとして発行することができます。OpenShift Pipelines の CloudEvents は下記リンクのようになっています。 https://tekton.dev/docs/pipelines/events/ https://tekton.dev/docs/pipelines/additional-configs/#configuring-cloudevents-notifications CloudEvents の HTTP ヘッダーの一部は下記のような形で送られてきます。PipelineRun が Failed の時、”Ce-Type” が “dev.tekton.event.pipelinerun.failed.v1” で送られてくる仕様なので、これを利用したいと思います。 "Ce-Id": "77f78ae7-ff6d-4e39-9d05-b9a0b7850527", "Ce-Source": "/apis/tekton.dev/v1beta1/namespaces/default/taskruns/curl-run-6gplk", "Ce-Specversion": "1.0", "Ce-Subject": "curl-run-6gplk", "Ce-Time": "2021-01-29T14:47:58.157819Z", "Ce-Type": "dev.tekton.event.taskrun.unknown.v1", 構築の概要 図のような構成を構築したいと思います。まず初めに、Pipeline Run からの CloudEvents を EventListener で受け取ります。次に EventListener は Pipeline Run が失敗したことを検知して TriggerBinding と TriggerTemplate から Slack に Webhook を送信するような Task Run を動作させます。Slack の指定したチャンネルに Pipeline Run 失敗通知が届けば動作完了です。 Slack App の準備 Slackに通知を送信するためには、 Slack App を作成し、適切な権限を付与する必要があります。Slack App の Webhook URL を取得し、OpenShift Pipelines で使用できるようにします。 Slack App のページから Create New App をクリックします。 From scratch をクリックします。 App Name を入力して、Slack App を追加するワークスペースを選択します。  Basic Information が表示されれば完了です。次に Incoming Webhooks をクリックします。 デフォルトでは Activate Incoming Webhooks は Off になっているので、クリックして On にします。 On になれば完了です。Add New Webhook to Workspace をクリックします。 Slack App が Slack ワークスペースに投稿する権限を与えます。投稿することのできる投稿先チャンネルを指定して許可します。 Webhook URL が作成されれば完了です。この Webhook URL は後に使うので Copy して保存しておきます。   Slack の通知を送信したいチャンネルに作成した Slack App が追加されていることを確認します。 Task の作成 Tekton Catalog を参考に Slack にメッセージを送信するための Task を作成します。この Task はシンプルなもので、Slack の Webhook URL に対して POST リクエストを送信します。 Secret を作成します。stringData の url に前項で保存した Slack API の Webhook URLを入力します。 webhook-url.yaml kind: Secret apiVersion: v1 metadata:   name: webhook-secret stringData: # 下記に前項で保存した Slack API の Webhook URLを入力   url: https://hooks.slack.com/services/ 下記コマンドを実行してWebhook URLを持つシークレットを作成します。 $ oc apply -f  webhook-url.yaml secret/webhook-secret created 下記コマンドを実行してシークレットが作成されていることを確認します。 $ oc get secret NAME                       TYPE                      DATA   AGE ︙ webhook-secret             Opaque                    1      17s Task の編集をします。params の中の bot-name の default を作成した Slack App の名前に置き換えます。 send-to-webhook-slack.yaml apiVersion: tekton.dev/v1beta1 kind: Task metadata:   name: send-to-webhook-slack   labels:     app.kubernetes.io/version: "0.1"   annotations:     tekton.dev/pipelines.minVersion: "0.12.1"     tekton.dev/categories: Messaging     tekton.dev/tags: messaging     tekton.dev/displayName: "Send message to Slack Channel"     tekton.dev/platforms: "linux/amd64,linux/s390x,linux/ppc64le" spec:   description: >-     These tasks post a simple message to a slack channel.     This task uses Incoming Webhooks of slack to send the message.   params:   - name: webhook-secret     type: string     description: secret name of the slack app webhook URL (key is url)   - name: message     type: string     description: plain text message     default: 'Webhook-test'   - name: bot-name     type: string     description: plain text message 　　# 下記を作成した Slack App の名前に変更     default: 'sample app'   - name: icon-emoji     type: string     description: plain text message     default: ':ロボット:'   steps:   - name: post     image: docker.io/curlimages/curl:7.70.0@sha256:031df77a11e5edded840bc761a845eab6e3c2edee22669fb8ad6d59484b6a1c4 #tag: 7.70.0     script: |       #!/usr/bin/env sh       MESSAGE=$(echo "${MESSAGE}" | sed -e 's/\"/\\\\"/g')       BOTNAME=$(echo "${BOTNAME}" | sed -e 's/\"/\\\\"/g')       JSON="{\"text\": \"${MESSAGE}\", \"username\": \"${BOTNAME}\", \"icon_emoji\": \"${EMOJI}\"}"       curl -X POST -H 'Content-Type: application/json' --data "${JSON}" "${URL}"     env:     - name: URL       valueFrom:         secretKeyRef:           name: $(params.webhook-secret)           key: url     - name: MESSAGE       value: $(params.message)     - name: BOTNAME       value: $(params.bot-name)     - name: EMOJI       value: $(params.icon-emoji) 下記コマンドを実行してタスクを作成します。 $ oc create -f  send-to-webhook-slack.yaml task.tekton.dev/send-to-webhook-slack created 下記コマンドを実行してタスクが作成されていることを確認します。 $ tkn task ls NAME                    DESCRIPTION              AGE send-to-webhook-slack   These tasks post a ...   43 seconds ago TriggerBinding の作成 TriggerBinding は、イベントデータを Task に渡すための設定です。パイプラインのエラー情報を Task に渡すための TriggerBinding を作成します。 下記コマンドを実行して TriggerBinding を作成します。 $ oc apply -f trigger_binding.yaml triggerbinding.triggers.tekton.dev/failure-trigger-binding created trigger_binding.yaml apiVersion: triggers.tekton.dev/v1beta1 kind: TriggerBinding metadata:   name: failure-trigger-binding spec:   params:   - name: message     value: "Failed pipeline $(body.pipelineRun.metadata.name)" 下記コマンドを実行して TriggerBinding が作成されていることを確認します。 $ tkn triggerbinding ls NAME                      AGE failure-trigger-binding   3 minutes ago TriggerTemplate の作成 TriggerTemplate は、イベントに応じて実行するリソースのテンプレートです。Task を実行するための TriggerTemplate を作成します。 下記コマンドを実行して TriggerTemplare を作成します。 $ oc apply -f trigger_template.yaml triggertemplate.triggers.tekton.dev/failure-trigger-template created trigger_template.yaml apiVersion: triggers.tekton.dev/v1beta1 kind: TriggerTemplate metadata:   name: failure-trigger-template spec:   params:     - name: message     - name: bot-name   resourcetemplates:   - apiVersion: tekton.dev/v1beta1     kind: TaskRun     metadata:       generateName: failure-handler     spec:       params:       - name: webhook-secret         value: webhook-secret       - name: message         value: $(tt.params.message)       - name: bot-name         value: $(tt.params.bot-name)       taskRef:         name: send-to-webhook-slack 下記コマンドを実行して TriggerTemplate が作成されていることを確認します。 $ tkn triggertemplate  ls NAME                       AGE failure-trigger-template   4 minutes ago EventListener の作成 OpenShift Pipelines で発生した CloudEvents を受け取るための EventListener を作成します。この EventListener は、interceptors の cel を利用して CloudEvents の内容を判別し、 HTTP ヘッダーの ”Ce-Type” が “dev.tekton.event.pipelinerun.failed.v1”  の場合に Slack にメッセージを送信する Task を実行します。 下記コマンドを実行して EventListener を作成します。 $ oc apply -f failure-event-listener.yaml eventlistener.triggers.tekton.dev/failure-event-listener created failure-event-listener.yaml apiVersion: triggers.tekton.dev/v1beta1 kind: EventListener metadata:   name: failure-event-listener spec:   serviceAccountName: pipeline   triggers:     - name: failure-trigger       interceptors:         - ref:             name: cel           params:           - name: "filter"             value: "header.match('ce-type', 'dev.tekton.event.pipelinerun.failed.v1')"       bindings:       - ref: failure-trigger-binding       template:         ref: failure-trigger-template   resources:        kubernetesResource:          spec:            template:              spec:                serviceAccountName: pipeline                containers:                - resources:                    requests:                      cpu: "250m"                      memory: "64Mi"                    limits:                      cpu: "500m"                      memory: "128Mi" 下記コマンドを実行して EventListener が作成されていることを確認します。 $ tkn eventlistener ls NAME                     AGE            URL                                                                   AVAILABLE failure-event-listener   1 minute ago   http://el-failure-event-listener.ci-pipeline.svc.cluster.local:8080   True 下記コマンドを実行して EventListener をルートとして公開します。 $ oc expose svc el-failure-event-listener route.route.openshift.io/el-failure-event-listener exposed 下記コマンドを実行して EventListener がルートとして公開されていることを確認します。 $ oc get route NAME                        HOST/PORT                                               PATH   SERVICES                    PORT            TERMINATION   WILDCARD el-failure-event-listener   el-failure-event-listener-ci-pipeline.apps.xxx          el-failure-event-listener   http-listener                 None 下記コマンドを実行して EventListener の webhook-url を確認します。この webhook-url は次項の CloudEvents の設定で使用します。 $ echo "URL: $(oc  get route el-failure-event-listener --template='http://{{.spec.host}}')" URL: http://el-failure-event-listener-ci-pipeline.apps.xxx CloudEvents の設定 cloud_events_config.yaml の data.sink パラメータに前項で取得した EventListener の webhook-url を入力します。 cloud_events_config.yaml apiVersion: v1 kind: ConfigMap metadata:   name: config-events   namespace: openshift-pipelines   labels:     app.kubernetes.io/instance: default     app.kubernetes.io/part-of: openshift-pipelines data:   formats: tektonv1 # ここに前項で取得した EventListener の webhook-url を入力   sink: http://el-failure-event-listener-ci-pipeline.apps.xxx 下記コマンドを実行して CloudEvents 設定をします。 $ oc apply -f config-events.yaml configmap/config-events configured 下記コマンドを実行して CloudEvents 設定が反映されていることを確認します。 $ oc describe configmaps config-events -n openshift-pipelines Name: config-events Namespace: openshift-pipelines ︙ formats: ---- tektonv1 sink: ---- http://el-failure-event-listener-ci-pipeline.apps.cp-test.cpawstest.ps.staging-test.sios.jp 動作確認 最後に、実際にパイプラインを実行して、エラーが発生した場合に Slack に通知が届くことを確認します。 以前の記事 のようにアプリケーションリポジトリに空のコミットを push します。 $ git commit -m "empty-commit" --allow-empty $ git push このままだと成功してしまうのでメッセージは送信されません。 パイプラインを少し編集してパイプラインが失敗するようにしてみます。 パイプラインの定義が記述されている pipeline.yaml 内の fetch-repository タスクの params を下記のように編集してこのタスクが失敗するようにします。 pipeline.yaml の詳細は 以前の記事 を参照してください。 tasks:   - name: fetch-repository     taskRef:       name: git-clone       kind: ClusterTask     workspaces:     - name: output       workspace: shared-workspace     - name: ssh-directory       workspace: ssh-creds     params:     - name: url # URL を適当な文字列に変更       value: "test"     - name: subdirectory 下記コマンドを実行して編集を反映させます。 $ oc apply -f pipeline.yaml 空のコミットをもう一度pushします。 $ git commit -m "empty-commit" --allow-empty $ git push 少し経った後、OpenShift コンソール上でパイプラインが失敗したことを確認します。 webhookを許可したSlackのチャンネルを確認してメッセージが送信されていれば完了です。   まとめ OpenShift Pipelines にエラー通知をSlackに送信する仕組みを Tekton Catalog  を参考にして構築してみました。OpenShift Pipelines では OpenShift コンソール上の GUI で通知機能を設定するような実装はありませんが、CloudEvents と EventListener を組み合わせて実装することが出来ました。次回は CD 部分である OpenShift GitOps のエラー通知機能を実装してみたいと思います。 参考文献 https://github.com/tektoncd/catalog/blob/main/task/send-to-webhook-slack/0.1/README.md https://tekton.dev/docs/pipelines/events/ https://tekton.dev/docs/pipelines/additional-configs/#configuring-cloudevents-notifications https://tech-lab.sios.jp/archives/44104 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post OpenShift Pipelines のエラー通知を Slack に送信してみた first appeared on SIOS Tech. Lab .

こんにちは！ 今月も「OSSのサポートエンジニアが気になった！OSSの最新ニュース」をお届けします。 2024/11/8、ウエルシア薬局は外部からの不正アクセスで個人情報が流出した可能性があると発表しました。 「ウエルシアドットコム」から約4万人分の個人情報漏えいのおそれ　従業員がサポート詐欺に https://www.itmedia.co.jp/news/articles/2411/08/news186.html 2024/11/18、オープンソースのコンピューター支援設計 (CAD) ツールである FreeCAD がリリースされました。 開発が開始されてから、実に 20年もの時間をかけて公開されることとなりました。 20年以上にわたり開発されてきた「FreeCAD」がv1.0として公開 ～長年の課題2つを克服 https://forest.watch.impress.co.jp/docs/news/1641700.html 2024/11/19、Microsoft は Windows Subsystem for Linux (WSL) の公式ディストリビューションに RHEL を採用したことを発表しました。 WSLにRed Hat Enterprise Linuxの公式ディストリビューション登場 https://news.biglobe.ne.jp/it/1122/mnn_241122_2370227770.html#google_vignette ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【2024年11月】OSSサポートエンジニアが気になった！OSS最新ニュース first appeared on SIOS Tech. Lab .

今号も、前号の「 パッケージマネージャについて 」の続きになります！ 今回は Red Hat 系システムの yum/dnf で、以前紹介できなかったサブコマンドについてご紹介します。 なお、前回と同様に dnf コマンドの実行例のみ掲載しています。 yum/dnf の便利なサブコマンド パッケージの情報を表示 dnf info コマンドを実行すると、特定のパッケージの詳細な情報を表示します。 例えば、git というパッケージの情報を表示する場合は、下記の様なコマンドになります。 # dnf info git … Available Packages Name : git Version : 2.43.5 Release : 1.el9_4 Architecture : x86_64 Size : 54 k Source : git-2.43.5-1.el9_4.src.rpm Repository : rhel-9-appstream-rhui-rpms Summary : Fast Version Control System URL : https://git-scm.com/ License : GPLv2 Description : Git is a fast, scalable, distributed revision control system with an : unusually rich command set that provides both high-level operations : and full access to internals. : : The git rpm installs common set of tools which are usually using with : small amount of dependencies. To install all git packages, including : tools for integrating with other SCMs, install the git-all meta-package. この時、結果には パッケージバージョン、ライセンス、要約 (説明文) など 、様々な情報が表示されます。 なお、上記のコマンドはネットワーク上のリポジトリから情報を取得してくるため、 対象のパッケージがインストールされていなくても情報が表示されます。 yum コマンドの場合は、下記の様になります。 # yum info git dnf/yum の実行履歴を表示 dnf history コマンドを実行すると、dnf コマンドの実行履歴を表示します。 # dnf history … ID | Command line | Date and time | Action(s) | Altered ------------------------------------------------------------------------------------------------------------------------ 8 | install git | 2024-11-14 01:44 | Install | 67 7 | install httpd | 2024-11-01 03:35 | Install | 12 6 | install tomcat | 2024-11-01 03:34 | Install | 17 5 | install wget | 2024-10-31 05:33 | Install | 1 4 | install net-tools | 2024-10-09 05:02 | Install | 1 3 | install telnet | 2024-09-20 04:55 | Install | 1 2 | -q -y --disablerepo=* --enablerepo=rhui-client-config* update | 2024-09-20 04:27 | Upgrade | 1 EE 1 | install postfix | 2024-09-20 03:05 | Install | 2 この時、結果には実際に実行したコマンド、実行した日時などが表示されます。 また、各操作には ID が割り振られており、 ID の数字が小さいほど古く、大きいほど新しい実行履歴となります。 yum コマンドの場合は、下記の様になります。 # yum history パッケージのリストを表示 dnf list コマンドを実行すると、特定の条件に合致するパッケージのリストを表示します。 例えば、git という文字列から始まるパッケージのリスト (一覧) を表示する場合は、下記の様なコマンドになります。 # dnf list git* … Available Packages git.x86_64 2.43.5-1.el9_4 rhel-9-appstream-rhui-rpms git-all.noarch 2.43.5-1.el9_4 rhel-9-appstream-rhui-rpms git-clang-format.x86_64 18.1.8-3.el9 rhel-9-appstream-rhui-rpms … (長いため省略) 上記は、ご利用環境で 有効になっているリポジトリから、指定した条件でパッケージを検索しています。 また、上記の条件に併せてインストール済みパッケージのみ、利用可能なパッケージのみ、などの条件に一致するリストを表示することができます。 例えば、git という文字列から始まるパッケージのうち、インストール済みのパッケージのみを表示する場合は、下記の様なコマンドになります。 # dnf list installed git* 反対に、git という文字列から始まるパッケージのうち、利用可能な (インストールされていない) パッケージのみを表示する場合は、下記の様なコマンドになります。 # dnf list available git* yum コマンドの場合は、それぞれ下記の様になります。 # yum list git* # yum list installed git* # yum list available git* ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 知っておくとちょっと便利！パッケージマネージャについて3 ～RedHat 系システム編・続き～ first appeared on SIOS Tech. Lab .

はじめに サイオステクノロジーの塚田です。Rancher入門ブログシリーズとして、 前回 はRancherの概要について説明しました。今回はAWS上にRancherを構築する方法について解説します。この記事では、Terraform、RKE2、Helmといったツールを使用して、AWS環境にRancherを簡単に構築する方法をステップバイステップで紹介します。 構築する環境のアーキテクチャは以下の通りです： 構成要素 リージョン: us-east-1 VPC: CIDR範囲: 10.0.0.0/16 Public Subnet: 10.0.0.0/24 10.0.1.0/24 10.0.2.0/24 Network Load Balancer (NLB): Rancherへの外部アクセスを負荷分散します。 EC2インスタンス: Control Planeノードとして3台を構成し、それぞれRKE2を使用したKubernetesとRancherをホストします。 OS: Ubuntu 24.04 LTS インスタンスタイプ: t3.xlarge ※1 セキュリティグループ: ノード間通信が行えるよう必要なポートを開放します。 ※1: 最低要件はt3.medium相当ですが、本記事では余裕を持たせて最低要件から2倍程度のインスタンスタイプを採用しています。 本記事のゴール AWS環境の準備: Terraformを用いて、AWS上に必要なリソース（VPC、サブネット、NLB、EC2インスタンスなど）を自動的に構築します。 Kubernetesクラスターの構築: RKE2 ※2 を使用して、高可用性を備えたKubernetesクラスターをセットアップします。 今回構築するのは検証用なので、Control PlaneとWorker Nodeを兼用します。 Rancherのインストール: Helmを利用してRancherをデプロイし、Kubernetesクラスター管理用のダッシュボードを利用できるようにします。 ※2 RKE2とは: Rancher Labsが開発したKubernetesディストリビューション https://docs.rke2.io/ 事前準備 構築を始める前に、以下の要件を満たしていることを確認してください： AWSアカウント: 適切な権限を持つIAMユーザーを用意してください。 本記事ではAdministratorAccessを利用しています。 ローカル環境にインストールが必要なツール: Terraform: v1.5.0以上 前提条件 KubernetesおよびRancherのバージョン 本記事で使用するソフトウェアのバージョンは以下の通りです： Kubernetes (RKE2): v1.30.6+rke2r1 Rancher Server: v2.10 ※3 cert-manager: v1.16.1（SSL証明書管理用） ※4 ※3: 本記事執筆時点での最新バージョン ※4: RancherはHTTPSを使用して動作するため、SSL証明書を管理するツールとしてcert-managerが必要です。 ハードウェア要件 EC2インスタンス最低スペック: CPU: 2コア以上 メモリ: 4GB以上 ストレージ: 20GB以上の空き容量 構築手順  AWSリソースの作成 まずはterraformを利用して、Kubernetesクラスター構築に必要なリソースをAWS環境上に作成します。 デモ用リポジトリ からterraformのコードをクローンします。 $ git clone git@github.com:Eiji-Tsukada-sti/rancher_demo.git $ cd rancher_demo terraformを実行します。 # terraformを初期化 $ terraform init # terraformで作成するリソースを確認 $ terraform plan # AWSにデプロイ $ terraform apply terraformのoutputより、以下の情報を確認してください。 initial_server_public_ip: 初回構築用インスタンスのIPアドレス instance_public_ips: 全インスタンスのIPアドレスリスト nlb_dns_name: NLBのDNS名 Kubernetesクラスターの構築（RKE2） 上記の手順で作成した各インスタンスにログインし、RKE2を利用してKubernetesクラスターを構築していきます。 初期サーバーの構築 RKE2公式ドキュメントの「 High Avalilability 」の内容に基づき、Control Plane3台構成で冗長化した構築を行います。設定ファイルの内容が1台目と2台目以降で異なるため、分けて記載します。 EC2インスタンスにSSH接続します。 秘密鍵はterraform実行時にterraformのコードと同じ階層に作成されます。 また、接続先のIPアドレスはterraformデプロイ完了時に出力されるinitial_server_public_ipの値を使用してください。 $ ssh -i rancher_demo_instance_key.pem ubuntu@<INITIAL_SERVER_PUBLIC_IP> 冗長構成用の設定ファイルを作成します。 $ sudo mkdir -p /etc/rancher/rke2 $ sudo vi /etc/rancher/rke2/config.yaml config.yamlに以下の内容を記載します。 YOUR_TOKENは任意の文字列を使用可能です。 /etc/rancher/rke2/config.yaml token: <YOUR_TOKEN> tls-san:   - <INITIAL_SERVER_PUBLIC_IP> RKE2をインストールします。 $ curl -sfL https://get.rke2.io | sudo sh - RKE2のサービスを起動します。 $ sudo systemctl enable rke2-server.service $ sudo systemctl start rke2-server.service RKE2のサービスの状態がActiveになっていることを確認します。 $ sudo systemctl status rke2-server.service インスタンス内でkubectlコマンドを実行できるよう設定します。kubectl自体はRKE2のインストール内容に含まれています。 $ sudo chown ubuntu:ubuntu /etc/rancher/rke2/rke2.yaml $ sudo chmod 644 /etc/rancher/rke2/rke2.yaml $ sudo ln -s /var/lib/rancher/rke2/bin/kubectl /usr/local/bin/ $ sudo mkdir ~/.kube $ sudo ln -s /etc/rancher/rke2/rke2.yaml ~/.kube/config kubectlコマンドでノード情報を取得し、ノードのステータスがReadyになっていることを確認します。 $ kubectl get nodes 残りのサーバーの構築 続いて、残りのインスタンスにRKE2を導入します。基本的な手順は1台目と同じですが、/etc/rancher/rke2/config.yamlの記載内容が1台目と異なります。 EC2インスタンスにSSH接続します。 秘密鍵はterraform実行時にterraformのコードと同じ階層上に生成されます。 接続先のIPアドレスはterraformデプロイ完了時に出力されるisntance_public_ipsの値のうち、残りの2つを使用してください。 $ ssh -i rancher_demo_instance_key.pem ubuntu@<INSTANCE_PUBLIC_IP> 冗長構成用の設定ファイルを作成します。 $ sudo mkdir -p /etc/rancher/rke2 $ sudo vi /etc/rancher/rke2/config.yaml config.yamlに以下の内容を記述します。2台目以降は”server”を追加します。 server: https://<INITIAL_SERVER_PUBLIC_IP>:9345 token: <YOUR_TOKEN> tls-san: - <INITIAL_SERVER_PUBLIC_IP> 初期サーバーと同じ手順でRKE2をインストール・設定します。 すべてのNodeのステータスがReadyで、RoleがControl Planeになっていることを確認します。 $ kubectl get nodes 3台のノードがControl Planeとして起動していることを確認したら、クラスターの構築は完了です。 config.yaml について config.yaml は、RKE2の動作を設定するためのファイルです。このファイルには、ノード間の通信や認証に必要な情報、クラスターの冗長構成を実現するための設定が含まれます。 具体的には以下の内容を設定します： server：クラスターに参加するために使用される接続先サーバー。 token：クラスター内でノードを認証するためのトークン。全てのノードで共通。 tls-san：サーバーのTLS証明書に追加のホスト名またはIPv4/IPv6アドレスをSubject Alternative Namesとして追加する。 Rancherのインストール 構築したクラスターにRancherをデプロイします。インストールする方法は様々な手段がありますが、本記事ではもっとも簡単な Helmを利用してインストールする方法 を採用しています。なお、この手順は3台のインスタンスの内、いずれか1つに実施すれば問題ありませんが、本記事では最初の1台目で実施します。 cert-managerのインストール Rancherは、クラスターへのセキュアなアクセスを確保するためHTTPSが必須です。そのため、SSL証明書を簡単に管理できるcert-managerを事前にインストールします。 EC2インスタンスにSSH接続します。 $ ssh -i rancher_demo_instance_key.pem ubuntu@<INITIAL_SERVER_PUBLIC_IP> Helmをインストールします。 $ sudo curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash cert-managerのHelmリポジトリを追加します。 $ helm repo add jetstack https://charts.jetstack.io $ helm repo update cert-managerをインストールします。 $ helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --set crds.enabled=true --version v1.16.1 cert-managerのPodが正常に起動しているか確認します。 $ kubectl get pod -n cert-manager Rancherのインストール cert-managerの準備が完了したら、Rancherをインストールします。 RancherのHelmリポジトリを追加 $ helm repo add rancher-latest https://releases.rancher.com/server-charts/latest $ helm repo update Rancherをインストールします。 $ helm install rancher rancher-latest/rancher \ --namespace cattle-system \ --create-namespace \ --set hostname=<NLB_DNS_NAME> \ --set replicas=3 \ --set bootstrapPassword=<YOUR_INITIAL_PASSWORD> \ --set ingress.tls.source=letsEncrypt \ --set letsEncrypt.email=<YOUR_EMAIL> RancherのPodが起動していることを確認します。起動が完了するまで数分程度かかります。 $ kubectl get pod -n cattle-system ブラウザにNLBのドメインを入力してアクセスします。もし、アクセスできない場合はrancherのPodの起動が完了していない可能性があるので、Podのステータスを確認してください。 RancherのUIに初回アクセスすると、初回パスワードの入力を要求されます。Helmのvalueとして設定したbootstrapPasswordの値を入力します。2回目以降のログインではRancherが自動生成した「New Password」を使うので、控えておいてください。 初回ログイン時はユーザーネームを要求されませんが、2回目以降のログイン時はユーザーネームの入力が必要です。デフォルトのユーザーネームは「admin」です。 利用規約に同意する（By checking the box~…の箇所）にチェックを入れて、「Continue」を押下します。 Rancherのホーム画面に遷移したことを確認します。構築が正常に完了していると、Rancherが稼働しているクラスター自身（画面内のlocalという名称のクラスター）が管理対象として登録されています。 サイドバーからlocalクラスターを選択すると、クラスターの詳細情報を見ることができます。 これでRancherの構築は完了です。RancherのUI画面から、クラスターや各種リソースの管理を開始できます。 構築時のトラブルシューティング RKE2のサービスが起動しない RKE2のサービス (rke2-server.service) が正常に起動しない場合、以下の点を確認してください。 必要なポートが開放されていない RKE2クラスターが正常に稼働するには、必要なポートが開放されている必要があります。ポートが開放されていない場合、サービスの起動が失敗します。 例：サービス起動失敗時のログ Nov 18 02:45:11 ip-10-1-2-193 rke2[66864]: time=”2024-11-18T02:45:11Z” level=fatal msg=”etcd cluster join failed: duplicate node name found, please use a unique name for this node” Nov 18 02:45:11 ip-10-1-2-193 systemd[1]: rke2-server.service: Main process exited, code=exited, status=1/FAILURE 対処方法： セキュリティグループの設定を見直し、RKE2の稼働に必要なポートが開放されているか確認してください。 Rancherの稼働に必要なポート要件については、公式ドキュメントPort Requirementsページの Ports for Rancher Server Nodes on RKE2 を参照してください。 ※RKE2だけではなく、Rancherの起動時にも利用するポート開放の設定は影響します。また、RKE2以外のディストリビューションでRancher用のKubernetesクラスターを構築した場合は、必要なポートが異なります。詳しくは、公式ドキュメント「Port Requirements」の Rancher Nodes の項目を参照してください。 config.yamlの設定ミス /etc/rancher/rke2/config.yaml の設定に誤りがあると、RKE2が正常に接続できず、サービスの起動に失敗する場合があります。特に、server パラメーターの設定ミスが原因で接続に失敗するケースがよく見られます。 対処方法： config.yaml に記載されている server パラメーターの記述が正しいか確認してください。特に、初期サーバーのIPアドレスやポート番号（9345）を間違えないように注意してください。 token がクラスター全体で一致していることを確認してください。 まとめ 今回の記事では、公式ドキュメントを参考に、AWS環境上にRKE2を利用してKubernetesクラスターを構築し、その上にRancher Serverを導入する手順を解説しました。Rancherを活用することで、クラスターの管理や運用を効率的に行える基盤を構築することができます。また、RancherはRKE2だけではなく、EKSなどのマネージドKubernetesサービスを含む他のKubernetesクラスターにも導入が可能なので、多様な運用要件に柔軟に対応することができます。 次回の記事では、今回構築したRancher Serverを活用して、マルチクラスターを管理する方法について解説します。複数のKubernetesクラスターを一元管理し、より高度な運用を行うための手法をご紹介しますので、ぜひご期待ください。 参考文献 RKE2のインストール（冗長構成） Rancher Serverのインストール ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Rancher入門：Rancher Serverの構築 first appeared on SIOS Tech. Lab .

こんにちは！安藤 浩です。11/22(金) に NexTech Week 2024【秋】に参加してきましたので、レポートします。 NexTech Week 2024【秋】 とは AI、ブロックチェーン、量子コンピュータ の最新テクノロジーとデジタル人材を育成するサービスが出展する4つの展示会で構成されます。 出展数は以下の通りです。 AI・人工知能 Expo :130社 ブロックチェーン Expo :41社 量子コンピューティング:20社 ブースの紹介 ブロックチェーン EXPOを中心に回ってきましたのでそちらのブースと講演の紹介をします。 connectiv NFT Garden  という企業向けのNFT生成プラットフォームを開発されています。 Web画面や API でNFT生成が可能とのことでした。 NFT をどう活用しようかというところで​  Snapshot  というリアルイベントの参加の記録、特典の利用などができるサービスを紹介されていました。 ダイナミック NFTで参加者がイベントでの条件をクリアするごとに、ビジュアルが変化し、達成度が分かる仕組みがありました。 株式会社クリプトリエ ミントモンスター  という NFTマーケティング・プラットフォーム でNFTを簡単に作成し、QRコードで配布できる仕組みです。 NFTの配布時にユーザにミッションを設ける、クーポンなどの特典を付与することができます。 NFTの配布で終わらない仕組みづくりがされていると思いました。 また、NFTをマーケティング活動としても利用できる機能も備えています。 内部的にウォレットの生成には NTT Digital の scramberry WALLET SUITE  が利用されているとのことでした。 参考:  クリプトリエ、NTT Digitalと「scramberry WALLET SUITE」の導入とNFTのビジネス活用におけるユースケースの協創について基本合意書を締結 ガイアックス 既存・新規事業DAO、採用系のDAO、自治体系のDAO などDAOの立ち上げ、運用支援をされており、立ち上げまで3カ月程度とのことでした。 DAOX  というサービスでDAOの立ち上げ、運用を行っているとのことです。海外のサービスとしては、  CharmVerse（チャームバース）  、  アラゴン  などがあります。実際、DAOという組織の運用においてリーダー的な立ち位置の人がいないと継続は難しそうという話もお聞きしました。 福岡県未来ITイニシアティブ 福岡県未来ITイニシアティブ  という福岡県の新産業振興課で実施している取り組みで、福岡県内のIT産業の発展を目指して、環境づくり、人材の育成を行っているとのことでした。そちらのブースにて共同出展されていたのは4社あり、 九州NFTラボ 、株式会社INTLEIR、  合同会社 暗号屋 、 株式会社ワーキングハセガワ  が出展されていました。 ちなみに、 福岡県未来ITイニシアティブ  主催の 福岡県ブロックチェーンフォーラム２０２４  が11/28に開催されるとのことです。 九州NFTラボ COMMUN  というスマホアプリ、プラットフォームを開発しており、訪問の証明としてNFTを配布サービスを提供しています。 企業がイベントを開催するときに イベント会場にIC カードを設置して、ユーザにNFC(ICカード)やQRコードでNFTを配布するということでした。 それらのNFTを活用して、訪問証明やクーポンが利用できるとのことです。訪問者限定のコンテンツ提供につなげようとしているとのことでした。 ブース内でQRコードを読み取り、 NFT を配布いただきました。 JPYC 株式会社 Ethereum、Polygon、Avalanche、Astarなどで発行しており、1JPYC=1円として利用できるERC20規格のステーブルコインです。  SDK  を利用してもよいし、Openzeppelinなどでも開発できるとのことでした。 JPYC のビジネスモデルについて疑問があったのでお聞きしたら、JPYCを発行し、その裏付け資産として国債を購入して、その運用益と関連事業の手数料収入などを収益にしているとのことでした。 N.Avenue株式会社 CoinDesk Japan を運用している会社です。費用は掛かりますが、「 N.Avenue Club 」で企業間のコラボレーションやネットワーキング出来るとのことでした。 参加企業は  こちら に記載されていました。 アーリーワークス GLS (Grid Ledger System) という世界最高水準の速度を誇る高速ブロックチェーンということで、1取引約0.2秒で完了するとのことです。 ブース内ではブロックチェーンを使って何ができるのかが記載された「ブロックチェーン活用事例集50」が紹介されていました。  実績  としてGLSを利用した不動産プラットフォームや要件定義を担当された MetaMe  が紹介されていました。 株式会社　シーエーシー KOUKA  という社内や組織間での貢献や称賛を表現するためにNFTを送ることができるシステムが紹介されていました。 貢献や称賛を可視化し、貢献度の高い社員を見つけられるということができるようです。 組織間(例：会社間)でも利用したいという用途を踏まえ、ブロックチェーンを利用しているとのことでした。 大手金融機関、損保系向けにCorda、EnterPrise Ethereum 、Hyperledger 系での開発経験があり、特にCordaの要員は多そうでした。 また、Japan Open Chain のバリデータでもあります。 マネックスグループ 株式会社 Monex Web3 ID（MID）  は最近オープンベータ版としてリリースされ、メールアドレスを使用した登録により自動的にウォレットが発行される仕組みです。 MIDは Polygon 上で発行されたNFTで、別ユーザに移転することができない Soulbound Token（SBT）とのことでした。 MIDに対してクエストのようなものを設定し、クリアすることでスコアとして表現することができるとのことでした。 今後の展望として、個人の属性情報の取得や行動履歴の証明につなげていきたいとのことでした。 旭化成株式会社 Akliteia  という偽造防止するラベルとサプライチェーン上の製品の流通をブロックチェーン上に記録するソリューションを紹介していました。 ラベルは複製が困難でめちゃめちゃ細かいパターンが印刷されていて専用のデバイスで真贋を判定するとのことでした。今までサプライチェーン上の製品をトラッキングするにはどうしたら良いのだろうと思っていましたが、こういう感じでするのだと興味を持ちました。 キリフダ株式会社 LINEでウォレットを自動生成しLINE内でNFTの配布、閲覧ができるサービスを提供しているとのことでした。 また、QRコードを読み取り、NFTを保有を認証する仕組みもあるようです。( NFTauth ) NEMTUS Symbol とSymbolを利用したサービスの普及をしているNPO法人です。周辺のブースの方は、Symbolと関連がある方が多かった印象です。 ボードで紹介されているのは個人で開発されたものが多めとのことでした。 株式会社NFTDrive NFTDrive  というフルオンチェーンを実現するサービスを提供しています。 画像、動画、圧縮ファイルなどをすべてSymbolのブロックチェーン上に保管する取り組みをされています。プライベートネットワークにも対応できるとのことでした。 Atomos-Seed合同会社 トークンの形・量・質の向上を図る トークンデザイン という考えをご説明いただきました。  Heartlog  というフルオンチェーン保存するNFTのサービスを紹介されていました。 こちらは先ほど紹介したNFTDriveを利用しているとのことです。 その他、紹介しきれませんでしたが、 株式会社Pacif i c Meta 、  株式会社SARAH  、  SUSHI TOP MARKETING株式会社  、  GCC  などを拝見させていただきました。 講演について 以下の2件聴講させていただきました。 1.「Web3の社会実装を実現する新規事業ノウハウについて」 主に  Grid Ledger System (GLS)  と  MetaMe  を題材にして話されていました。 MetaMe  は共通の価値観を持つ人と関われるコミュニケーション空間を提供するサービスです。 NFT レコメンド機能、トークングラフを利用して、ファンの熱量などの可視化できなかった部分を可視化できるようになるとのことでした。 また、ユーザにNFTを利用しているということを感じさせない作りを意識しているように思いました。 DAOのような組織だったり、特別誰が担当という決まっていないような作業に対して、貢献度や報酬を可視化することでユーザにメリットがあるのではないかという話が上がっていました。 2.「NFT活用によるメディアイベントの新たな価値創出」 みんなのあしあと を事例にお話しされていました。コンテンツを送るだけではなく、ユーザとの永続的なつながりを意識しユーザのコミュニティを意識してイベントやSNS、配信などでクロスセルを行っていく戦略についてのお話しをされていました。スポーツだったらスポーツ番組、イベント、大会、ボランティア、アウェイツーリズム などで経済活動を活性化するというところ進めると良さそうというお話しでした。 まとめ エンドユーザやブロックチェーンの仕組みでマーケティングしたい、イベント開催したいというサービスを提供しているところが多かった印象。 NFTの配布や所有などによってどうユーザが活用、メリットを生み出すかというところを各企業さんが注力されているように思いました。 AI の企業も数社お聞きしましたが、よりプロンプトや操作が簡単なもので精度高く期待のデータが得られることに注力しているような印象でした。 NexTech Week 2025【春】は2025年4月15日（火）～17日（木）に 東京ビッグサイト（東展示棟）で開催されるようです。ぜひ参加されてはいかがでしょうか。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【イベントレポート】NexTech Week 2024 秋 – ブロックチェーン Expo – に参加してきました！ first appeared on SIOS Tech. Lab .

こんにちは！安藤 浩です。今回はAzure AI Studio でのプロンプトフローの構築とプロンプトフローの評価についてご説明します。 Azure AI Studio とは Azure で提供される AI 関連のサービスを 1 つのプラットフォームにまとめたものです。 AI関連のサービスを一元管理でき、簡単にアプリ開発や AI モデルの構築、評価ができます。 プロンプトフロー とは プロンプトフローとはLLMを含むAI アプリケーションの開発を実現できる開発ツールです。 GUIで処理と処理のつながりを可視化でき、評価も実施できます。 フローの種類には標準フロー、チャットフロー、評価フローなどがあります。 以下では、プロンプトフロー の基本的な使い方を紹介します。 プロンプトフローの実行方法 AI Studio を開き、ツール > プロンプト フローを押下します。 作成ボタンを押下します。 ローカルからアップロード の アップロードボタンを押下し、右側にアップロード画面が開くので、フォルダを参照して、アップロードします。 ここではもっとも  簡易的なチャットフロー のサンプル  を例にアップロードしてみます。 また、フローの種類の選択は Chat Flow を選択します。 アップロードが完了すると、以下の画面が表示され、左側にフローが表示されます。 ここで接続の箇所で既にDeploy済のGPTを指定します。 「コンピューティング セッションを開始」を押下して、コンピューティング セッションを開始します。 コンピューティング セッションの開始は数分かかります。 コンピューティング セッション実行中のとなりのチャットボタンでチャットをすることができます。 プロンプトフローの評価方法 続いて、プロンプトフローの評価方法を説明します。 ツール > 評価 を押下します。 「＋New evaluation」ボタンを押下します。 Prompt flow を選択します。 「評価するフローを選択する」で上記で作成したプロンプトフローを選択します。 「評価するデータを選択する」の箇所で「データセットの追加」で「ファイルをアップロードする」ボタンを押下して以下のdata.jsonl をアップロードします。 {"query":"What is the capital of France?", "ground_truth": "Paris","response": "","context": "","history": "[]"} {"query":"What is the capital of Japan?", "ground_truth": "Tokyo","response": "","context": "","history": "[]"} {"query":"What is ChatGPT?","ground_truth":"ChatGPT is a form of generative AI -- a tool that lets users enter prompts to receive humanlike images, text or videos that are created by AI.","response":"","context":"","history": "[]"} {"query":"What is Machine learning (ML)?","ground_truth":"Machine learning (ML) is a branch of and computer science that focuses on the using data and algorithms to enable AI to imitate the way that humans learn, gradually improving its accuracy.","response":"","context":"","history": "[]"} ※Machine Learning のGround Truth は  https://www.ibm.com/topics/machine-learning  より引用。 プロンプトフローのデータセットマッピングで、以下のようにマッピングします。 設定したら、次へを押下します。 AI品質の箇所、マッピングは以下のように設定します。 ここではコンテキストは利用しないので、根拠性、関連性はチェックしません。 設定出来たら、次へを押下します。 内容を確認して「送信」を押下すると評価が開始されます。 実行結果が出るまで時間がかかりますが、以下のような結果が表示されます。 メトリックス AI Studio でのプロンプトフローの評価では以下のようなメトリックスがあります。 メトリックス 説明 コヒーレンス 生成されたテキストの一貫性と自然性を評価する。言語モデルが、スムーズに流れ、自然に読み取られ、人間のような言語に似た出力を生成できる程度を測定する。 流暢性 モデルの回答の言語能力を評価するために使用されるメトリック。生成されたテキストが文法規則、構文構造、ボキャブラリの適切な使用方法にどの程度準拠しているかを評価し、言語的に正しく自然に聞こえる応答であるかを評価する。 類似性 正解の文 (またはドキュメント) と AI モデルによって生成された予測文の類似性を測定する。 F1スコア モデルの予測とソース データ (グラウンド トゥルース) の間で共有される単語の数の比率を測定する。 グランド度 モデルの生成された回答が入力ソースからの情報とどの程度整合しているかを評価する。 関連性 モデルの生成された応答がソースのデータからの情報とどの程度関連するかを測定する。 メトリックスとその説明 評価結果の結果の解釈 上記の結果のインデックス:0,1 でコヒーレンス、流暢性、類似性はいずれも5で高い値です。Ground Truth(人間が入力した値) と一致しています。 インデックス:2,3 についてはコヒーレンス、流暢性は高いですが、上記に比べると類似性はやや少し低くなっていますが、Ground Truth(人間が入力した値)の入力よりも回答のほうがより詳細な説明になっているのでこのような値になったのだと思います。F1の値は回答のほうがより詳細な説明なので低い値になっていると推測します。 インデックス:2 の回答の冒頭の内容(翻訳済)は以下のようになっています。Ground Truth をもう少しより詳細にしたほうが良かったのではと思います。 ChatGPT は OpenAI が開発した会話型 AI モデルで、GPT (Generative Pre-trained Transformer) ファミリーの一部です。入力に基づいて人間のようなテキストを理解して生成するように設計されています。ChatGPT は会話に参加したり、質問に答えたり、説明を提供したり、自然言語を処理することで幅広いトピックを支援したりすることができます。 インデックス:3 の回答の冒頭の内容(翻訳済)は以下のようになっています。インデックス: 2と同様により詳細な説明がなされています。 機械学習 (ML) は人工知能 (AI) のサブセットであり、コンピューターがデータから学習し、特定のタスクごとに明示的にプログラムすることなく予測や決定を行えるようにするアルゴリズムとモデルの開発を伴います。 ML システムは、静的な一連のルールに従うのではなく、より多くのデータにさらされるにつれて時間の経過とともにパフォーマンスが向上します。 ### 機械学習の主要な概念: 1. **学習の種類:** - **教師あり学習:** モデルはラベル付きデータでトレーニングされます。つまり、各トレーニング例は出力ラベルとペアになっています。目標は、入力から出力へのマッピングを学習することです。 まとめ 簡単なチャットの例でしたが、Azure AI Studio でのプロンプトフローの実行とプロンプトフローの評価の方法について説明しました。 AI Studio でのプロンプトフローの評価はプレビュー版ですが、作成したプロンプトフローの妥当性を測るために有用なツールなので利用してみてはいかがでしょうか。 参考URL Azure AI Studio でのプロンプト フロー Azure AI Studio を使用して生成 AI アプリを評価する方法 生成 AI の評価と監視メトリック Prompt flow ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Azure AI Studioによるプロンプトフローの構築と評価入門 first appeared on SIOS Tech. Lab .

以前の記事 では、CI 部分を担う OpenShift Pipelines の構築を行いました。続いて、本記事では実際に CD 部分となる OpenShift GitOps を構築して デプロイ先の状態変化を検知してマニフェストファイルの状態を保ち続ける pull 型のデプロイを実装してみたいとおもいます。 構築の概要 前回構築したCIパイプラインと組み合わせて図のような CI/CD パイプラインを OpenShift 上に構築します。 OpenShift GitOps ハンズオン の一部を参考にしています。前回と同様にチュートリアルではパブリックリポジトリを利用していますが、実際構築する際はプライベートリポジトリであるケースが多いため、プライベートリポジトリで構築してみます。CD 部分の動作については OpenShift GitOps がクラスター内のリソースとマニフェストリポジトリを監視しており、マニフェストを正として常にクラスター内のリソースとの同期をとります。必要な作業としては OpenShift GitOps のインストール、マニフェストリポジトリの登録、マニフェストを OpenShift 上にデプロイするためのアプリケーション設定になります。 事前準備 下記構成のプライベートなマニフェスト用Git リポジトリを用意します。アプリケーションをデプロイするためのマニフェストファイルが格納されています。 app ├── deployment.yaml ├── kustomization.yaml ├── route.yaml └── service.yaml deployment.yaml 内の image tag には アプリケーションGitリポジトリ側のコミットIDを参照します。コミットIDは git側でも確認が可能ですが、CI パイプライン実行後に下記コマンドを実行して image stream の tag を参照する方が簡単です。 $ oc get imagestream -n pipelines-tutorial NAME IMAGE REPOSITORY TAGS UPDATED ocp-cicd-appli-ui image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/ocp-cicd-appli-ui 974d59ed90012de8d19e47a5e74807018d08c5ae 26 minutes ago deployment.yaml apiVersion: apps/v1 kind: Deployment metadata:   labels:     app: ocp-cicd-appli-ui   name: ocp-cicd-appli-ui spec:   replicas: 1   selector:     matchLabels:       app: ocp-cicd-appli-ui   template:     metadata:       labels:         app: ocp-cicd-appli-ui     spec:       containers:         - image: image-registry.openshift-image-registry.svc:5000/ci-pipeline/ocp-cicd-appli-ui:<image tag>           imagePullPolicy: Always           name: ocp-cicd-appli-ui           ports:             - containerPort: 8080               protocol: TCP kustomization.yaml resources: - deployment.yaml - service.yaml - route.yaml route.yaml apiVersion: route.openshift.io/v1 kind: Route metadata:   labels:     app: ocp-cicd-appli-ui   name: ocp-cicd-appli-ui spec:   port:     targetPort: 8080-tcp   to:     kind: Service     name: ocp-cicd-appli-ui     weight: 100 service.yaml apiVersion: v1 kind: Service metadata:   labels:     app: ocp-cicd-appli-ui   name: ocp-cicd-appli-ui spec:   type: NodePort   ports:     - name: 8080-tcp       port: 8080       targetPort: 8080       protocol: TCP   selector:     app: ocp-cicd-appli-ui 前提条件 OpenShift クラスターが構築済みであること oc CLI がインストール済みであること 前回の記事 でCIパイプラインが実行されており、imageがopenshift-image-registryにプッシュされていること OpenShift GitOps をインストール OpenShift OperatorHub で Administrator のパースペクティブにいることを確認します。 Web コンソールで[Operators] > [OperatorHub]に移動します。 検索バーに「OpenShift GitOps」と入力して、 OpenShift GitOps をクリックして Install をクリックします。 デフォルトのまま Install をクリックします。 OpenShift GitOps のログイン 下記コマンドを実行してArgo CD へアクセスする URLを確認します。 $ oc get route openshift-gitops-server -o jsonpath='{.spec.host}' -n openshift-gitops 取得した URL に Web ブラウザからアクセスします。 下記コマンドを実行して admin ユーザでログインするためのパスワードを確認します。 $ oc extract secret/openshift-gitops-cluster --to=- -n openshift-gitops # admin.password <password> Usernameに admin と Password に上記のコマンドで取得したパスワードを入力し、Argo CD にログインします。 ArgoCD の ホーム画面が表示されれば完了です。 OpenShift GitOps 構築 Argo CD へのデプロイ権限の付与 下記コマンドを実行して Argo CD の Service Account (openshift-gitops-argocd-application-controller) に対して、対象の Project に対する edit 権限を付与します。 $ oc adm policy add-cluster-role-to-user edit system:serviceaccount:openshift-gitops:openshift-gitops-argocd-application-controller プライベートリポジトリの登録 Github で Personal access token の発行をします。 Settings -> Developer Settings -> Personal access tokens にいき、Generate new token をクリック（Personal access tokens (classic) を選択）します。 Personal access tokenが発行されるのでそれをメモしておきます。 ArgoCD ダッシュボードから Settings -> Repositories にいき、Connect Repo をクリックします。 下記パラメータを入力して [CONNECT] をクリックします。 登録したリポジトリに対する CONNECTION STATUS が Successful になったら完了です。 Choose your connection method: VIA HTTPS Project: default Repository URL: GitHubリポジトリのURL（末尾が .git で終わるURL） Username: 任意 Password:上記でメモしたPersonal access token アプリケーションのデプロイ（GUI操作） GUI か CLI いずれかでアプリケーションのデプロイを行います。 Argo CD ダッシュボードから [+ NEW APP] ボタンをクリックし、以下の内容を入力し Argo CD アプリケーションを作成します。 Application Name: sample-app Project: default Sync Policy: Automatic Repository URL: GitHubリポジトリのURL（末尾が .git で終わるURL） Revision: HEAD Path: app Destination: https://kubernetes.default.svc Namespace: pipelines-tutorial Sync Policy は Manual と Automatic を選択できます。今回はクラスターへのマニフェストリポジトリの反映を自動で行うために Automatic に設定します。クラスターへの反映にワンクッション（SYNCボタンを押す動作を）挟みたい本番環境などのユースケースでは Manual を選択します。 ダッシュボードにアプリケーションが作成されていれば成功です。 アプリケーションのデプロイ（CLI操作） 下記コマンドを実行してアプリケーションのデプロイを行います。ダッシュボードにアプリケーションが作成されていれば成功です。   $ oc apply -f application.yaml application.argoproj.io/sample-app created application.yaml application.yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata:   name: sample-app   namespace: openshift-gitops spec:   project: default   source:     repoURL: GitHubリポジトリのURL(末尾が .git で終わるURL)     path: app     targetRevision: HEAD   destination:     server: https://kubernetes.default.svc     namespace: pipelines-tutorial # Sync Policy を Manual にする場合は下記を削除   syncPolicy:     automated: {} 動作テスト マニフェストの変更とデプロイ マニフェストファイルを編集します。 deployment.yaml のレプリカ数を変更 (1->3) します。 deployment.yaml apiVersion: apps/v1 kind: Deployment metadata:   labels:     app: ocp-cicd-appli-ui   name: ocp-cicd-appli-ui spec:   # replicas: 1   replicas: 3   selector:     matchLabels:       app: ocp-cicd-appli-ui   template:     metadata:       labels:         app: ocp-cicd-appli-ui     spec:       containers:         - image: image-registry.openshift-image-registry.svc:5000/ci-pipeline/ocp-cicd-appli-ui:<image tag>           imagePullPolicy: Always           name: ocp-cicd-appli-ui           ports:             - containerPort: 8080               protocol: TCP ダッシュボード上を確認して、Pod が3つデプロイされていれば成功です。 OpenShift 上のリソースが削除された場合のセルフヒーリングの確認 下記コマンドを実行して、OpenShift 上のリソースを削除します。  $ oc delete route ocp-cicd-appli-ui -n pipelines-tutorial route.route.openshift.io "ocp-cicd-appli-ui" deleted [DETAILS] ボタンより [SYNC POLICY] > [SELF HEAL] の [ENABLE] ボタンを押します。 Argo CD が Git リポジトリと OpenShift の状態の差異を検知し、自動的にリソースが復旧されることを確認します。 他にも以下のコマンドを実行して、OpenShift 上のリソースが自動的に復元されることをダッシュボード上で確認します。 $ oc delete svc ocp-cicd-appli-ui -n pipelines-tutorial service "ocp-cicd-appli-ui" deleted $ oc delete deployment ocp-cicd-appli-ui -n pipelines-tutorial deployment.apps "ocp-cicd-appli-ui" deleted リソース削除時の挙動の確認 Git リポジトリから route.yaml ファイルを削除し、kustomization.yaml から route.yaml の行をコメントアウトします。 kustomization.yaml resources: - deployment.yaml - service.yaml # - route.yaml [DETAILS] ボタンより [SYNC POLICY] > [PRUNE RESOURCES] の [ENABLE] ボタンをおします。 Route のリソースが OpenShift 上から削除されることを確認します。 まとめ 本記事では実際に OpenShift GitOps のハンズオンを参考にしてOpenShift Pipelines の CI 部分に連携する CD 部分を構築してみました。これでビルドの自動化からアプリケーションのデプロイまでの CI/CD パイプラインを実現できました。 参考文献 https://github.com/mamoru1112/openshift-gitops-handson         ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post OpenShift GitOps を構築してみた first appeared on SIOS Tech. Lab .

本ハンズオンでは、Azure OpenAI Serviceを活用したRAG（Retrieval-Augmented Generation）の導入から本格的なシステム構築までを段階的に学べます。 上級編では、Azure OpenAIとサーバーレステクノロジーを組み合わせ、本番環境での運用に対応できる実践的なRAGシステムの構築手法を学びます。生成AI技術の理解を深め、応用力を高めたい方に最適な内容です。 ご興味がある方はお早めにお申し込みください。 【上級編】Azure OpenAIとサーバーレステクノロジーを駆使したRAGシステム構築ハンズオン 〜本番環境での運用に対応できる実践的なRAGシステムの構築〜 ＜概要＞ Azure OpenAI Serviceと生成AIの概要 RAGの基礎概念 生成AIに特化した検索手法 AzureでRAGを実現するために必要なサービス ハンズオン ＜日時＞ 2024年12月5日（木）10:00～17:00（受付9: 30～） ＜場所＞ 〒106-0047 東京都港区南麻布2-12-3　サイオスビル3F ＜得られるスキル＞ Azure OpenAI Serviceの基礎 Azure OpenAI Serviceがどのようなサービスであり、どのように利用するのかを学ぶことができます。これにより、クラウドベースのAIサービスの活用方法を理解し、自身のプロジェクトに適用するための基礎を築くことができます。 本番でRAGを動かすために必要なアーキテクチャの習得 本番環境での運用に対応できる実践的なRAGシステムのアーキテクチャを学びます。Azure FunctionsやAzure Static Web Apps、Azure AI Document Intelligenceなどの最新サーバーレス技術を活用し、柔軟かつスケーラブルなシステムを設計するための知識を習得します。 RAG構築方法 実際にRAGを構築するための基本的な手順を学びます。 ハンズオンを通じて、 独自データの準備から外部データベースへの登録、 そして生成AIを用いた回答生成までの流れを体験し、 実践的なスキルを身につけることができます。 ＜費用＞ 有料 ＜定員＞ 24名（先着順） ＜対象者＞ 本番環境での運用に対応できる実践的なRAGシステムの構築を検討される方   【有償】支援サービス 上級テクニカルトレーニング Azureの最先端技術を駆使したRAGハンズオンです。 このハンズオンでは、最新の検索手法である「 セマンティックハイブリッド検索」、Azure Static Web Apps、Azure Functionsによるフルサーバーレス構成など、 最新技術を用いたRAGの構築方法をお伝えします。 業務委託・技術支援 当社では、AIだけでなく、 クラウドネイティブなアプリケーション開発、 既存システムのクラウド移行・モダナイゼーション、 システムの基盤構築など、 クラウドを中心としたシステム開発あるいは技術支援なども行って おります。システムでの困り事がありましたら、 ぜひご相談ください。 チャットボット作成 (RAGツール開発) RAG(Retrieval-Augmented Generation)を中心に、 話題の生成AIを活用した業務の効率化、 DX化をお手伝いいたします。社内ノウハウの見える化、 カスタマーサポートの省力化、 チャットボットアプリケーションの導入など、 社内資源の有効活用をお考えの場合は、ぜひご相談ください。 AI関連アプリ開発 既存のアプリ・システムを、もっと便利に・ 楽にできないかお考えですか？RAGやLangChain などにより生成AIを活用すれば、 今まで以上により業務効率を上げるのに効率的なアプリの開発を行 うことができます。 まずはコンサルティングという形からご相談いただくことも可能で す。AIで迷われたら、ぜひご相談ください。 Azure CSP販売・技術支援 Azureのライセンス販売を通じてお客様のビジネスをご支援し ています。 Azureライセンスの提供からAI技術のコンサルティングまで 全て当社にお任せください。​​​​ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【12/5開催：上級編】Azure OpenAIとサーバーレステクノロジーを駆使したRAGシステム構築ハンズオン 〜本番環境での運用に対応できる実践的なRAGシステムの構築〜 first appeared on SIOS Tech. Lab .

サイオステクノロジーの菊地啓哉です。今回は、Solidity のプログラムを開発・実行できるWeb IDE の Remix で、MetaMask が使えなくなるという現象が発生して、解決できたので、その情報の共有です。 「こうしたら解決できた」というだけの内容なので、とっても薄い内容になってます。 環境 Google Chrome Chrome の拡張機能の MetaMask 起こったこと ある時、検証のために Remix で SmartContract を開発し、Remix VM ではなく実際のチェーン上で実行したかったので、ENVIRONMENT で Injected Provider - MetaMask を選ぼうとしたところ、反応が、、無い…！？ ここで選択しても、切り替わらない 解決のためにやったこと 早速結論です。 MetaMask のアクセス許可リストから、Remix を一度削除しました。 Remix上で次に操作した際にアクセス許可が求められ、正常に利用できるようになりました。 ということで、もう少し詳細を。 MetaMask の拡張機能の右上の3点リーダーで開かれるメニューから、「すべてのアクセス許可」を選択 Remix（remix.ethereum.org）を選択 最後に「すべてのアカウントを接続解除」から接続を解除します。 先に書いた通り、ここで接続を解除しても、また使おうとすると許可を求められて、許可すれば以前と同様に利用できました。 最後に 原因は何だったんでしょう？ MetaMask側のセキュリティアップデートか、Remix側のアップデートかはわからないですが、少し様子を見てもネット上で問題になっているようなことも見受けられなかったので、個人の環境の問題だろうという推測はたっていました。 MetaMask を入れなおしたりする手間に比べると格段に手軽にできるので、Remix に限らず、MetaMask が使えていたはずなのに急に使えなくなった際には試してみても良いかもしれません。 今回は薄っぺらいですが、以上になります。 またかきます またね ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Remix で MetaMask が使えなくなったけど解決できた話 first appeared on SIOS Tech. Lab .