こんにちは。サイオステクノロジーの木村です。 サーバーのメンテナンス作業などを行う際に、サイトにアクセスしてきたユーザーに通常の画面を表示せずに「メンテナンス中画面」を表示する方法について記載します。 通常の画面表示とメンテナンス画面の表示を簡単に切り替えられるよう、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 .

生成AIの分野でもRAGは特に注目を集めており急成長している分野です。あまりに多くの情報に溢れており、各手法をどう捉えてよいか分かりにくい状況にあります。このブログではRAGがどのように成長し、どのような改善が試みられているのかを整理して、包括的で体系的に理解できるような説明を試みました。読んでいただいた方の理解の助けになれば幸いです。 RAGの概要 LLMは非常に優れた効果を発揮したものの、嘘を答えてしまうハルシネーションや古い知識での応答、回答の根拠の分からない不明瞭な推論といった問題を抱えています。RAGはこれらの課題に対し外部データベースを取り入れるというアプローチで解決を試みており、特に注目を集めている分野であり急速に進化しています。また、外部データベースを取り入れるという特性からドメイン固有の知識とLLMを組み合わせることができるため、企業からも大きな注目をされており研究・開発を実施されています。 基本的なRAGシステムのシナリオは図1のようになります。まず、ユーザがシステムに対して質問を投げかけます。システムは質問を元にデータベースに関連するドキュメントを問い合わせます。そのドキュメントを元にLLMが回答を生成しユーザに提供します。これによりユーザは従来の単純な検索システムよりもLLMを介することによって柔軟な質問でデータにアクセスしたり、的確な回答を得ることを期待できます。 (図1: 基本的なRAGの動作。 Retrieval-Augmented Generation for Large Language Models: A Survey [ 1 ]より引用) しかし、単純な方法では期待されたほどの効果は得られないことが分かってきており、現在は様々な改善が試みられているという状況です。その改善について説明していきます。 RAGの進化とパラダイム RAGのパラダイムはNaive RAG、Advanced RAGを経て、Modular RAGへと進化しています。Naive RAGは最も基本的なRAGでシンプルですが多くの課題を抱えています。Advanced RAGはNaive RAGのフローをベースとして各処理の改善したものとなっています。さらに、Modular RAGでは、RAGで必要な各処理をモジュール化し、それらを組み替えることで新たなパターンを生み出して大きな性能の改善を試みています。 Naive RAG (Baseline RAG) Naive RAG（Baseline RAGと呼ばれることもあります）は最も素朴なRAGのことです。インデクシングではPDFやWord、Markdownの文書データをプレーンテキストに直した後に固定のトークンの長さ（100, 256, 512など）でチャンクに分割。チャンクごとのベクトル表現を計算し、ベクトルデータベースに格納します。検索ではユーザの質問をベクトル表現に変換し、データベースから類似度の高いコンテンツを検索して、ドキュメントから回答を生成します。 このRAGは大きなの欠点を抱えていると指摘されています[ 1 ]。 検索の課題: 検索の再現性や精度が悪く、不揃いで無関係なチャンクがヒットし、重要な情報が欠落してしまうという。 回答生成の困難: RAGでも単にLLMを利用する場合と同様に ハルシネーションを起こすことがあり、無関係であったり、有害であったり、バイアスのある情報を出力しうる。 検索結果の統合のハードル: 検索さらた複数の結果をうまく統合できずに適切な応答ができないことがある。多くの文書から関連性や重要性を判断し、統合して、一貫性のある回答を引き出すことは困難である。これらには一度の検索処理では不十分である。 1度でもRAGを構築されたことがある方なら頷ける内容ではないかと思います。RAGは基本的にこれらの課題を解決しようと進化を続けています。 Advanced RAG Advanced RAGはNaive RAGの基本的な処理フローを踏襲しつつ、検索や回答生成など各処理の品質の向上に着目し、回答の精度の改善をしようとしています。 (図2: Naive RAGとAdvanced RAGとModular RAGの処理イメージ。 Retrieval-Augmented Generation for Large Language Models: A Survey [ 1 ]より引用) 図2のAdvanced RAGのオレンジ部分がNaive RAGに対し追加されているテクニックです。Advanced RAGのテクニックはもう少し複雑であったり他のオプションを含むものなので、この図で完全に表されている訳ではありませんが、インデックス化、検索手法、回答生成のそれぞれに対して改善しているのがAdvance RAGです。これらの改善については 改善手法 のセクションで紹介します。 Modular RAG 単純にRAGの質問、検索、回答生成という線形なプロセスの工程をそれぞれ改善するだけでは限界がみえてきました。そこで、Modular RAGはNaive RAGやAdvanced RAGを基本としつつ、RAGの機能のモジュール化により適応性と再利用性を向上しようとしています。図2のようにModular RAGではRAGの各機能がモジュールとなり、それらを組み合わせた「パターン」をちょうどLEGOブロックのように組み上げていくという方法をとります。 より具体的にModular RAGの内容を見ていきます。Modular RAGは次の3層に分かれたアーキテクチャを持ちます。 モジュールタイプ (Module Type) モジュール (Module) 演算子 (Operator) モジュールタイプは最上位のレイヤーで、RAGのインデックス作成や検索、生成といった工程を表します。モジュールは中間のレイヤーで、各工程で実施する機能でチャンク化やクエリルーティングなどのより具体的な機能を表します。最後に演算子は最下位のレイヤーで、構造化インデックスやHyDEなど具体的な実装を表します。 このような3層の抽象化を用いることで自在な組み合わせを実現します。図3はモジュール、サブモジュール、演算子の具体例です。 (図3: Modular RAGのモジュールの一覧。 Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks [ 2 ]より引用) インデックス作成 (Indexing)、検索 (Retrieval)、検索事前処理 (Pre-Retrieval)、検索事後処理 (Post-Retrieval)、回答生成 (Generation)という従来のRAGの機能をモジュールしたもののほかに、オーケストレーション (Orchestration)が存在します。オーケストレーションはModule RAGの重要なモジュールタイプで、異なるモジュール間の調整役を担います。データやクエリに基づいて適切なモジュールを選択してフローを制御することで、より多くのデータやクエリに対して適応できるようになります。 Modular RAGはツールやフレームワークを利用することで実現することができます。Modular RAGを実現するツールやフレームワークをいくつかご紹介します。 Cognita は Langchain/LlamaIndex のラッパーのように動作し、RAGで必要なモジュールを提供し、 Langchain/LlamaIndex を単体で用いるよりも再利用性が高まります。 Advanced RAGが構築可能な Haystack と軽量なAI/機械学習の構成管理フレームワークである Hypster を組み合わせることで実装することもできます[ 3 ]。 AutoRAG はモジュールの組み合わせを自動的に選択できるという特徴を持つツールです[ 4 ]。G-EvalやRAGAsといった評価ツールを用いて、自動評価を実施し適切なパターンを走査してくれます。 まだ、この領域は発展途上であり成熟したツールは存在していませんが、注目度が高く変化が激しい状況です。今後さらに発展する領域と考えられ注視していく必要があります。 RAGの進化の過程 ここまでみたようにRAGはNaive RAG、Advanced RAG、Modular RAGという変遷を辿っています。これらのパラダイムは全く別ものではなく、前のパラダイムを拡張・改善する形で進んできています。Advanced RAGはNaive RAGの各処理をより洗練させ、Modular RAGはAdvanced RAGの処理をモジュール化し、その組み合わせのパターンによるより柔軟なアーキテクチャで非常に大きな工夫の余地を与えてくれています。また、最新のModular RAGというパラダイムが出たので、Advanced RAGは終わったかというとそういう訳ではなく、Advanced RAGにおける改善手法は現在でも進化を続けており、それがModular RAGのモジュールとなり進化していくという流れは続いています。そういう意味で今後しばらくの間は特定のパラダイムだけでなく全体を追っていく必要があります。 RAGとファインチューニング RAGとファインチューニング（追加学習）は類似した技術であるためしばしば比較されます。ここではRAGとファインチューニングの関連について説明します。 RAGとファインチューニングの違い RAGとファインチューニングはどちらもモデルがもともと持っていない情報をモデルに取り扱わせるという意味で同じですが、両者の方法はそれぞれことなります。RAGは前述の通りで外部のデータベースから情報を参照し、その情報を元に回答を生成します。通常、RAGでは事前学習されたモデルをそのまま使います。一方で、ファインチューニングはモデル自体にさらに追加の学習を行わせるという方法で、モデル自体（LLMのニューラルネットワークのパラメータ自体）が更新されて新しい情報を取り込みます。ファインチューニングは質問とそれに対する回答のセットである「学習データ」を用いてモデルを調整します。OpenAIなどのプラットフォームではこのような学習データをアップロードするだけで、ファインチューニングできる仕組みが提供されています[ 5 ]。 ファインチューニングは特定用途のタスクに対して効果的な能力を発揮します。例えば、特定ドメインの思考方法やより厳格な推論能力を向上などに効果が発揮されています[ 7 ]。しかし、多くの学習を行うと以前に学習したことを忘れてしまうといった「破壊的忘却」をしたり、学習した情報を回答できるようになってもその根拠を示せなかったり、新しいデータが更新されるたびにファインチューニングの手間がかかるといった課題があります。 RAGはファインチューニングがブラックボックス化してしまうのに対し、インデックス作成や検索・回答生成などの段階が見える形で存在しているためカスタマイズしやすかったり、データベースを更新すること情報が更新できるので最新を保ちやすいという特徴があります。しかし、RAGの回答は検索の品質に大きく依存しているため、RAGの構築は検索の工夫がどれだけできるかにかかっているとも言えます。 RAGとファインチューニングの性能 Microsoft Researchによる論文ではファインチューニングに対して、RAGの方が性能が高いと報告されています[ 6 ]。 (図4: Oren Elisha, Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs [ 6 ]より引用。) この検証ではRAG単体が最も性能が良く、次にRAGとファインチューニングの組み合わせ、最後にファインチューニングという順で性能が高いという結果になりました。Llama2に関してはファインチューニングとRAGの組み合わせが最も高い結果となりました。したがって、検索という観点ではRAGが優れているでしょう。 RAGとファインチューニングの融合 検索ではRAGが優れていたからといってRAGだけを用いるだけでなく、RAGとファインチューニングは両方を活かすことができます。 前セクションの論文では知識を正しく取り出せるかに着目しており、それ以外のタスクに関する検証は行なっていないので、単純にファインチューニングがRAGより一般的に劣っていると判断する材料にはなりません。例えば、専門分野における推論能力の向上では専門分野のコーパスを用いてファインチューニングさせることで性能が向上されたことが報告されています[ 7 ]。このようなタスクに関しては原理的にRAGで対応することは難しいでしょう。 つまり、図5のように外部知識が必要となるタスク（External Knowledge Required）ではRAGが有効で、モデル適応が必要となるタスク（Model Adaptation Required）ではファインチューニングがより有効です。Moduler RAGではファインチューニングされたモデルを組み合わされる方法が使われてきています。 (図5: Retrieval-Augmented Generation for Large Language Models: A Survey [ 1 ]より引用) 改善手法 RAGで提案されている改善を次の3つに分けて紹介していきます。 インデックス 検索 回答生成 インデックス チャンク化戦略 チャンク手法はRAGに取り込む大きな文書の塊を小さく分割する手法です。分割されたチャンクごとにインデックスが作成されるため、チャンクは検索の品質に大きな影響を与えます。ここの内容は 「 Chunking Strategies for LLM Applications 」[ 8 ]の内容を参考に説明します。 固定サイズチャンク 最も単純でNaive RAGで用いる方法が固定のチャンクサイズで機械的に分割する手法です。固定サイズのチャンクではチャンクサイズにはトークン数が用いられます。トークンとはTokenizerによって分割される単位です。通常は単語数や文字数ではないです。どのようにトークン分割されるかは Tokenizer – OpenAI Platform などを使って試すことができます。また、単純に固定のチャンクサイズで切ってしまうと文章の前後の繋がりの情報が失われてしまうため、隣り合ったチャンクで同じトークンを重複してもつ「オーバーラップ」を設ける必要があります。 この方法は自然言語処理（NLP）を必要としないため、計算量が小さいというメリットがありますが、全く文章の意味が考慮されないため、チャンクの質は悪くなりがちというデメリットがあります。 コンテンツ認識チャンク 固定サイズのチャンクは機械的で意味が考慮されないという点で、チャンクの質が悪いという問題点がありました。それに対し、コンテンツをきちんと認識した上で、より有効なチャンク化しようという方法もあります。その方法をいくつか紹介していきます。 (表1: 5つのコンテンツ認識チャンク。下の行ほど高度に意味を認識して分割するチャンク化方式。) チャンク方法 説明 文の分割 (Sentence splitting) 区切り文字などを利用して文に分割してチャンクとして扱う非常に簡単な方法です。実装は単に「。」などの句点で分けるコードを自作する方法 (Naive splitting) があります。だた、そのような方法では例外的なパターンなどでは分離できないので、NLTKやspaCyなどのPythonのライブラリによって文を分割という方法も用いられます。ライブラリを用いることでより適切に文を分離することができます。 再帰的チャンク化 (Recursive Chunking) 大きな文章をいくつかの文書に分割し、さらにその文書を分割するという処理を繰り返し、階層的かつ反復的に小さいチャンクに分割する方法です。再帰は指定されたチャンクサイズになるまで繰り返されます。分割には複数の区切り文字を使用します。再帰が繰り返される中で使用される区切り文字が変わり、目的のチャンクサイズになるように処理されます。実装はLangChainのRecursiveCharacterTextSplitterを用いる方法があります。 ドキュメント固有のチャンク化 (Specialized chunking) MarkdownやLaTexなどといった文書は構造化されていて、見出し、リスト、コードブロックなどの情報を用いることで、より正確にコンテキストを理解したチャンクを得ることができます。実装はLangChainのMarkdownTextSplitterやLatexTextSplitterを用いる方法があります。その他のドキュメントでも形式が明確なものであれば正規表現等を用いて、Splitterを自作することも可能でしょう。 意味的チャンク化 (Semantic Chunking) Greg Kamradtによって導入された手法です。その名の通りで文章の意味によってチャンクに分解します。文章を文に分割し、文の意味が近いものを同じトピック、遠いものがあれば別トピックに切り替わったと判断して、チャンクに分解します。上記の文章の表面的な形式で分割していたのに対し、より踏み込んだチャンク化です。実装はLangChainのSemanticChunkerを用いる方法があります。 エージェントによるチャンク化 (Agentic Splitting) さらに先進的な手法として実験的ではありますが、AIエージェントによる分割も提案されています[ 10 ]。 ベクトル化 分割されたチャンクは埋め込みモデル (Embedding Model) によってベクトル化されます。モデルの選定やチューニングについてご紹介します。 埋め込みモデルの選定 ベクトル化では意味の近いベクトルは類似度が近く、意味が遠いものは類似度が遠くなる分類性能の高いベクトル化されることが望ましいです。そのため、埋め込みモデルの選定はインデックスの品質に影響します。多くの場合では、OpenAI社の ada v2などのモデルを利用することが多いですが、 モデルの選択はリーダーボードを確認し、指標を比較して独自にモデルを選ぶことができます。リーダーボードでは多くのモデルに対しベンチマークを実施してその結果が公開されています。例えば、有名なリーダーボードとしては MTEB Leaderboard や Nejumi Leaderboard などがあります。特にNejumi Leaderboardは日本語での性能を評価したもので、日本語を扱う際のモデル選定では参考になります。 埋め込みモデルのファインチューニング 医療や法律など専門用語などは一般的な語用とは異なる場合があり、意図したベクトル化がされないことがあります。そのような場合には埋め込みモデルのファインチューニングが有効なケースがあります。 LLamaIndex などではファインチューニングが可能です。 構造インデックス インデックスの構造によっても検索の精度が変わります。ここではいくつかのインデックスの方法について「 Advanced rag techniques: an illustrated overview 」[ 9 ]を中心にご紹介します。 ベクトルストアインデックス (Vector store index) 最も単純に質問と回答のベクトルの類似度の近いものを検索する方法です。Naive RAGで使われる最初のアイデアです。ベクトル類似度と近傍探索のアルゴリズムは複数あります。 まず、ベクトルの類似度の計算についてElasticSearchでよく次の演算が使われています[ 11 ]。これらはElasticSearch固有の概念ではなく、数学や物理、情報工学で広く使われています。 マンハッタン距離 (L1距離) ユークリッド距離 (L2距離) コサイン類似度 ドット積 (内積、点乗積) 意味ベクトルは方向によって意味が表される性質があるので、RAGの文脈ではコサイン類似度やドット積といった「点」ではなく「ベクトル」として扱われる演算が相性がよく比較的精度がよいといえます。また、コサイン類似度はベクトルの角度のみが考慮されますが、ドット積はベクトルの長さも考慮されるのでより多くの情報を持ちます。しかし、情報が多ければよいというわけでもなく、長さがノイズになる場合もあるため比較して検討が必要となります。 次に近傍探索についてみていきます。近傍探索とは周辺にあるベクトルを探すためのアルゴリズムです。その方法には主に次の2つが存在します。 k最近傍法 ( k-Nearest Neighbor: kNN ) 近似最近傍法 (Approximate Nearest Neighbor: ANN) kNNはすべてのデータを比較して近いベクトルを見つけ出すアルゴリズムで、正確にベクトルを見つけ出すことができます。しかし、単純に全てのベクトル同士の距離を比較してしまうと、すべてのデータを探索することになり検索に非常に大きな時間がかかってしまうことになります。ちょうどリレーショナルデータベースでインデックスのないカラムに線形検索するようなものです。そのため、データベースとしては小規模〜中規模程度のデータベース向けで、大規模の場合にはRAGの応答性を犠牲にしても正確性を求める場合に利用します。 ANNは多少正確さを犠牲にして素早く近傍のベクトルを見つけるためのアルゴリズム全体の総称です。現在はその主流のアルゴリズムとしてHierarchical Navigable Small World (HNSW)が使われています。HNSWのアルゴリズムを簡単に説明します。図6のようにベクトルの近さをグラフとして表現し、グラフの詳細度で複数のグラフを構築します。この際に各グラフに対応するノードを設けます。このグラフを粗い方からたどり、クエリのベクトルに近いノードを探します。次にそのノードに対応する1段詳細度の高いグラフに移動し、もう一度探索します。最後は実際のベクトルと対応したグラフに移動し、最も近い（可能性が高い）ノードを発見します。イメージ的には札幌・仙台・東京・名古屋・大阪・福岡くらいしか書いていない広域の地図から場所を探して、次に関東周辺の地図から神奈川あたりが近そうだと分かり、神奈川県の地図から横浜みなとみらいを探し当てる感じといったところかと思います。 (図6: Hierarchical Navigable Small Worlds (HNSW) [ 12 ]より引用) HNSWでもかなり正確な結果が得られることが一般に知られています。そのため、アルゴリズム選択にあたってはANN近傍探索はまずANNから検討を始め、どうしてもそれでは検索精度が悪い場合にはkNNを選択するという進め方がよいでしょう。 多くのデータベースでは計算方法や近傍探索アルゴリズムを変更できるパラメータが用意されています。サポートされている計算方法・近傍探索はデータベースにより異なりますので、ドキュメントをご確認ください。 チャンクのメタデータ チャンクにページ番号やファイル名、カテゴリ、タイムスタンプなどのメタデータを付与する方法があります。チャンク生成時にデータベースにこれらのメタ情報を一緒に保存するように実装します。このメタデータで検索範囲の絞り込みをしたり、タイムスタンプでの絞り込みで古い情報を排除するなどして検索の精度を高めることができます[ 1 ]。 階層的インデックス (Hierarchical indices) (図7: Advanced rag techniques: an illustrated overview [ 9 ]より引用) 大規模なドキュメントを検索する際に細切れの小さなチャンクでは適切にコンテキストを保持できないという欠点がありました。そこで階層的インデックスのアプローチでは図7のように要約のチャンクに対して検索を実施し、さらに要約に関連づけられたより小さなチャンクを検索するという方法をとります。階層は要約の単位を変えることで複数に増やすことができます。これにより関連性の高いドキュメントを発見したり、要約の階層のドキュメントを回答に使うことができるなどのメリットがあります[ 13 ]。 実装についてはNirDiamant氏により参考となる Hierarchical Indices in Document Retrieval が公開されています。 想定質問（Hypothetical Questions） Naive RAGではユーザからのクエリをベクトル化することで検索を行いますが、質問のベクトルから内容のベクトルを検索するという動きになり、それらは必ずしもベクトルが類似するとは限りません。そこで、質問のベクトルから質問を検索したり、回答のベクトルから回答を検索するといった方法が提案されました。 想定質問（またはReverse HyDE）は質問のベクトルから質問を検索する方法で、インデックスの作成時点で内容に対する想定質問をLLMに生成させ、その質問をベクトル化したものをデータベースに格納します。例えば、「富士山の標高は3,776mです」というチャンクに対して、その文章そのもののベクトルでなく、LLMで質問「富士山の標高は？」という想定質問を生成します。この文章に対するベクトルをベクトルストアに保管します。するとユーザが質問した「富士山の高さはどのくらい？」との類似度が高くなる可能性が高く精度が高くなると予想できます。 Reverse HyDEと呼ばれている理由はHyDE（後述）が質問に対する「想定回答」で検索するというアプローチをとっており、その逆のアプローチであることからそのように呼ばれています。 周辺コンテキスト拡充 (Context enrichment) インデックス作成時にチャンクに周辺の文章を付与してLLMに推論させる方法です。LLMは検索したチャンクだけでなく周辺の文章を用いることができるので、文脈をよりよく理解して回答を生成することが期待できます。センテンスウィンドウ検索と自動マージ検索の2つの方法があります。 センテンスウィンドウ検索 (Sentence Window Retrieval)は単純に検索されたチャンクの周辺の文章をLLMに送る方法です。下図の緑の部分が検索で引っかかったチャンクであり、拡大して黒の文章を付与します。 (図8: Advanced rag techniques: an illustrated overview [ 9 ]より引用) 自動マージ検索 (Auto-merging Retriever (別名 Parent Document Retriever))はチャンクを親と子に分けて検索する方法です。まずは通常通り小さいチャンク（これを「子チャンク」という）に対して検索を行い、ヒットした子チャンクの属する親のチャンクを取得し、より大きな親チャンクの方をLLMに送る手法です。 (図9: 自動マージ検索のイメージ。 Advanced rag techniques: an illustrated overview [ 9 ]より引用) 具体的な実装については例えばLlamaIndexを使った方法で Recursive Retriever + Node References を参照ください。 ナレッジグラフ (Knowledge Graph) これまでのところはクエリに対していかに近い文章を取得したり、いかに周辺の文章も含んでコンテキストを保持するかがメインのテクニックでした。しかし、これだけでは不十分でクエリとは直接関連しなくとも、検索された文書とは関連して回答したい内容については取得できず、十分な回答が生成されなかったり、ハルシネーションを起こすという欠点がありました。 ナレッジグラフはそのような欠点を解決するために知識と知識を関連付けたグラフ型のデータベースを構築し、ベクトルストアデータベースよりも関連した情報を包括的に検索できるように考えられています。 ナレッジグラフの動作について簡単に説明します。ナレッジグラフとは図10のようなノード（丸）とエッジ（線）からなっており、ノードで対象となるオブジェクトを表し、エッジでそれらの関係性を表すグラフとなっています。RAGではノードに対してチャンクを割り当て、チャンク間の関連をエッジで表します。これによりベクトルストアインデックスで表現できなかった関連性を表現することができます。 (図10: LangChainのLLMGraphTransformerで構築したナレッジグラフをNeo4jで表示した例。 Enhancing RAG-based application accuracy by constructing and leveraging knowledge graphs [ 14 ]より引用) 検索は多くの場合ベクトルストアインデックスと併用で実装されるケースが多いです。手順としてはまず質問に対してベクトルストアからチャンクを取得し、そのチャンクに関連する情報をナレッジグラフから検索するという方法です。 (図11: ベクトルストアインデックスとナレッジグラフの併用。 Enhancing RAG-based application accuracy by constructing and leveraging knowledge graphs [ 14 ]より引用) 実装についてはLangChainのLLMGraphTransformerを用いる他に、現在注目されているのが、Microsoft Researchにより提案されている GraphRAG です。Graph RAGは2段階のナレッジグラフを用いて、部分的な知識の要約を1段階目で生成し、2段階目でその要約全体を用いて質問するため、従来手法より回答精度が高いとされています[ 15 ]。 検索 複合検索とハイブリット検索 (Fusion retrieval or hybrid search) 複数の検索手法を用いることで検索精度を向上させようとする方法は多く用いられています。基本的にはベクトル検索がベースとしてもちいられ、ベクトル検索の弱点を補う形で用いられることが多いです。特に代表的なものをご紹介します。 キーワード検索 ハイブリッド検索では多くの場合、ベクトル検索とキーワード検索の両方を用いることをいいます。キーワード検索とは単語や語句から文書を検索することを言います。RAGでは質問に含まれる単語や語句を自然言語処理によって抜き出してきて、一致したキーワードを含む文書を見つけ出します。 これはベクトル検索が意味として近い文章を見つけ出すのが得意なものの、同じキーワードが含まれていたとしてもベクトルの類似度が低ければ検索にヒットしないという弱点を克服するために用いられる方法です。 セマンティック検索 セマンティック検索は語句や単語の「意味」を基に検索をする検索方法です。例えば、「携帯」という単語から「ケータイ」「電話」や「iPhone」など似た意味の単語もヒットします。 これもキーワード検索との併用の効果と同じく、類似度が低くても近い意味合いの単語が使われているチャンクを取得することができます。 タグ検索 前述の チャンクのメタデータ で紹介した通り、あらかじめチャンクにメタデータを付与しておくことで、データを絞り込み検索精度を向上することができます。 グラフ検索 前述の ナレッジグラフ で紹介したとおり、ナレッジグラフを用いることで関連する文書より包括的に取得できるようになり、検索精度を向上することができます。 クエリ ユーザから提示された質問は必ずしも検索に対して最適とは限らず、クエリに対し何らかの工夫を施した方が検索精度が上がるといわれています。 クエリ拡張 単一のクエリだけを用いるのではなく、複数のクエリを使ったり、1つのクエリをより簡単なクエリに分割する検索の精度を上げる手法です。クエリ拡張には次の種類があります。 マルチクエリ (Multi-Query) サブクエリ (Sub-Query) マルチクエリ (Multi-Query)はユーザからのクエリを別の観点を取り入れて複数のクエリを生成する手法です。これにより単一のクエリだけでは取得できなかった結果を取得することができます。ユーザからのクエリの微妙なニュアンスの違いでベクトル検索にヒットしないような内容も取得できるといった効果が期待できます。実装では MultiQueryRetriever を使う方法があります。実際にMultiQueryRetrieverを使ってクエリを生成すると次のようになります。 元のクエリ: What are the approaches to Task Decomposition? (和訳: タスク分解へのアプローチは何ですか?) 質問1: How can Task Decomposition be achieved through different methods? (和訳: さまざまな方法でタスク分解を実現するにはどうすればよいでしょうか?) 質問2: What strategies are commonly used for Task Decomposition? (翻訳: タスク分解に一般的に使用される戦略は何ですか?) 質問3: What are the various ways to break down tasks in Task Decomposition? (和訳: タスク分解でタスクを細分化するさまざまな方法は何ですか? ) ( MultiQueryRetriever より引用・改変) このようにさまざまな聞き方の質問に変換されていることがわかります。これにより多くの情報を得られる可能性が高まります。 サブクエリ (Sub-Query)はユーザからのクエリを複数のクエリにより簡単なクエリに分割して検索する手法です。ユーザからの質問は複数の質問が関連したものであることがあり、そのようなケースでは一度のクエリでは解決できず、単純な質問に分割して検索することで的確な情報を取得できる効果が期待できます。実装はプロンプトエンジニアリングを使用して、質問を分割するようにLLMに指示します。実装例は Part 7: Decomposition – Rag From Scratch: Query Transformations に示されていますので参考としてください。実際にクエリを生成すると次のようになります。 元のクエリ: how to use multi-modal models in a chain and turn chain into a rest api (和訳: チェーン内でマルチモーダル モデルを使用し、チェーンを REST API に変換する方法) 質問1: How to use multi-modal models in a chain?  (和訳: チェーン内でマルチモーダル モデルを使用するにはどうすればよいでしょうか?) 質問2: How to turn a chain into a REST API? (和訳: チェーンを REST API に変換するにはどうすればいいですか?) ( Decomposition より引用・改変) このように複数のトピックが含まれているような質問が分割されていることがわかります。 クエリ変換 クエリ変換は元のクエリを変換することで、検索の精度を上げる手法です。よくある方法としては次があります。 HyDE Step Back HyDEは回答のベクトルから回答を検索する方法で、質問に対する回答を検索なしでLLMに作成させ、その質問をベクトル化したものでデータベースから検索します。検索なしで回答させるという点について不思議に思われるかもしれませんが、これは検索しなくともニュアンスの似た回答が得られるはずだという仮説に基づきます。例えば、元のクエリが「日本で一番高い山は何ですか？」であった場合に検索を用いずにLLMから「日本で一番高い山は高尾山です」という仮の回答を得ます。これは当然ハルシネーションですが、チャンクに「日本で一番高い山は富士山です。」という文章が含まれていれば、仮の回答とチャンクのベクトルは近いはずです。実際にBM25やContrieverと比較して精度が高いことが報告されています[ 16 ]。実装については Part 9: HyDE – Rag From Scratch: Query Transformations に示されていますので参考としてください。 Step Backは元のクエリをより抽象的な質問にLLMで変換させ、元のクエリと抽象的な質問の両方を使って検索を実施する手法です。これにより主に複数の情報源から結果を導き出すマルチホップ推論が必要な場面での精度が向上されたと報告されています[ 17 ]。実装については Part 8: Step Back – Rag From Scratch: Query Transformations に示されていますので参考としてください。 ルーティング 検索は1回だけではなく、複数回実施するのも有効な手段です。 (図12: 反復検索と再帰検索と適応検索のフローチャート。 Retrieval-Augmented Generation for Large Language Models: A Survey  [ 1 ]より引用。) 単一検索 Naive RAGで使われる単純な検索方法で、一度の検索で得られた結果を用いて回答を生成する方法です。シンプルな手法で応答性も高いものの、一度の検索では適切な回答を得られないことが多いという課題があります。 反復検索 反復検索は以前の検索結果を用いて、関連する文書を繰り返し取得する方法です。これにより周辺のコンテキストを補うことが期待できます。ただし、ノイズとなる情報が増えてしまうこともあります。 再帰検索 再帰検索は以前の検索結果を用いて、Chain-of-Thought (CoT) を用いてクエリを改善し、繰り返し検索をする方法です。この方法では検索結果のフィードバックを受けて、徐々に関連性の高い文書を探し当てることができます。 適応検索（AIエージェント） 適応検索とはLLMが次の検索をどのようにするかの次のアクション自体を考えさせるという方法です。最近特に注目を集めているのは適応検索の領域です。Flare、Self-RAG、AutoRAG、Toolformer、 Graph-Toolformerなどのツールが提案されていますが、ここでは より注目度の高いAIエージェントを用いたマルチドキュメントエージェント型の手法について簡単に説明します。   (図13: マルチエージェント型のアーキテクチャ例。 Advanced rag techniques: an illustrated overview [9]より引用) 図13のようにエージェントは担当するインデックスごとのドキュメントエージェントが配置され、ドキュメントエージェントを総括するトップエージェントの構造からなります。ドキュメントエージェントはトップエージェントに指示に合わせて、ベクトルストアインデックスと要約のインデックスなどデータベースへの問い合わせを自立して判断し実施します。トップエージェントはクエリをどのように分割して、各ドキュメントエージェントに引き渡したり、回答を統合したりについて判断します。これにより異なるドキュメントからの情報を統合した高度で洗練された回答得ることが可能になります。しかし、この手法はエージェント間の多段で複雑なクエリと回答の段階を踏むため、応答に時間がかかるというデメリットもあります。実装はLlamaIndexの Multi-Document Agents を用いることができます。 回答生成 再順位付けとフィルタリング 検索では必ずしも関連性の高い文書だけがヒットするわけではなく、関連性が薄くノイズとなるものも混在します。検索で得られた結果を改めて関連性の高い順番に並べ替えたり、フィルタリングするという方法がよくとられます。LlamaIndexの調査では再順位付けを実施することで精度が高くなるといわれています[ 18 ]。 LLMのファインチューニング RAGとファインチューニングの有効 で述べた通り、単純な知識の検索ではRAGが優れるものの、RAGとファインチューニングは両方を用いることができます。GPT-3.5-Turboをファインチューニングし、RAGAsでの評価を行った結果、回答の関連性や忠実性が向上したと報告されています[ 19 ]。 レスポンスシンセサイザー 最終的な応答生成は複数のチャンクを用いて回答を生成することになります。要約だけを示すような回答に調整したり、詳細まで説明を加えたり、精度を少々犠牲にしてLLMのトークン消費を節約するなどのケースが考えられます。LlamaIndexでは Response Synthesizer という機能を提供しており、その中で回答生成方法のオプションをいくつか用意されています。 まとめ RAGのパラダイムはNaive RAG、Advanced RAG、Modular RAGに進化している。 Advanced RAGではインデックス化、検索、回答生成のそれぞれに改善が提案されている。 Modular RAGでは多くの手法をモジュール化し、組み合わせパターンを柔軟に作り出す。 最後までお読みいただきありがとうございます。お気付きの点などありましたら、ぜひコメントください。 【宣伝】生成AI ネクストテックソリューションのご紹介 弊社サイオステクノロジーでは生成AIを用いたトレーニング、コンサルティング、アプリケーション開発のソリューションを提供しています。ご興味のある方はぜひお問い合わせください！ https://nextech-solutions.sios.jp/genai/ 参考文献 Yunfan Gao, Yun Xiong, Xinyu Gao, Kangxiang Jia, Jinliu Pan, Yuxi Bi, Yi Dai, Jiawei Sun, Meng Wang, Haofen Wang, Retrieval-Augmented Generation for Large Language Models: A Survey , 2024. Yunfan Gao, Yun Xiong, Meng Wang, Haofen Wang, Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks , 2024. Gilad Rubin, Implementing “Modular RAG” with Haystack and Hypster , 2024. Dongkyu Kim, Byoungwook Kim, Donggeon Han, Matouš Eibich, AutoRAG: Automated Framework for optimization of Retrieval Augmented Generation Pipeline , 2024. OpenAI, Fine-tuning Fine-tune models for better results and efficiency . Oded Ovadia, Menachem Brief, Moshik Mishaeli, Oren Elisha, Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs , 2024. 森下皓文, 山口 篤季, 森尾 学 , 今一 修 , 十河 泰弘, 日立製作所 研究開発グループ, シェフィールド大学, 帰納的に多様な巨大論理推論コーパスによりLLMの汎用論理推論能力を向上させる , 2024. Roie Schwaber-Cohen, Chunking Strategies for LLM Applications , 2023. IVAN ILIN , Advanced rag techniques: an illustrated overview ,  2023. Greg Kamradt, 5 Levels Of Text Splitting , 2024. Valentin Crettaz, Vector similarity techniques and scoring , 2024. Pinecone, Hierarchical Navigable Small Worlds (HNSW) . Nirdiamant, Hierarchical Indices: Enhancing RAG Systems , 2024. LangChain, Enhancing RAG-based application accuracy by constructing and leveraging knowledge graphs , 2024. Darren Edge, Ha Trinh, Newman Cheng, Joshua Bradley, Alex Chao, Apurva Mody, Steven Truitt, Jonathan Larson, From Local to Global: A Graph RAG Approach to Query-Focused Summarization , 2024. Luyu Gao, Xueguang Ma, Jimmy Lin, Jamie Callan, Precise Zero-Shot Dense Retrieval without Relevance Labels , 2022. Huaixiu Steven Zheng, Swaroop Mishra, Xinyun Chen, Heng-Tze Cheng, Ed H. Chi, Quoc V Le, Denny Zhou, Take a Step Back: Evoking Reasoning via Abstraction in Large Language Models , 2024. Ravi Theja, Boosting RAG: Picking the Best Embedding & Reranker models , 2023. LlamaIndex, Fine Tuning GPT-3.5-Turbo . ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post RAGはどのように進化しているのか？RAGのパラダイムと改善手法を体系的にご紹介！ first appeared on SIOS Tech. Lab .

はじめに CPチームの木下です。 今回はKubernetes（K8s）の運用は複雑で、クラスタ管理に多くの知識と労力が必要となりますが、そのKubernetes管理を大幅に簡素化するOSSのRancherについて記載していきます。 Rancherはマルチクラウドやハイブリッドクラウド環境における効率的な運用を支援するプラットフォームです。本記事では、Rancherの特徴やメリットについて分かりやすく解説します。 Rancherの主な特徴について   1. マルチクラスタ管理 Rancherは、複数のKubernetesクラスタを一元管理できるOSSです。オンプレミスのKubernetesから、Amazon EKS、Azure AKS、Google GKEといったクラウドのマネージドKubernetesまで、さまざまな環境のクラスタを一つの管理画面で操作できます。 メリット: 運用者は、分散したクラスタを一元的に監視・管理できるため、オペレーションの効率が向上し、複数のKubernetes環境を持つ運用者や企業に最適です。 ユースケース: マルチクラウド戦略を採用している企業や、オンプレとクラウドを組み合わせたハイブリッド環境の運用を行う企業・プロジェクトに適しています。 2. 直感的なユーザーインターフェース Rancherのダッシュボードは、Kubernetesを扱ったことがない人でも分かりやすく設計されています。ワンクリックでクラスタの作成や管理、リソースのデプロイが可能です。 ビジュアル化された管理画面: クラスタの状態、ノードやポッドのリソース使用量、ログなどを簡単に可視化できます。 初心者でも使いやすい: GUIベースで提供されるRancherの操作画面は、Kubernetesの専門知識が少ない人でも利用しやすく、学習コストを大幅に削減できます。 3. RBAC（Role-Based Access Control）機能 Rancherは、KubernetesのRBACをさらに強化し、ユーザーごとに細かい権限設定が可能です。開発者や運用者に応じたアクセス権限の付与や、部署ごとのリソース制限など、きめ細やかなセキュリティ管理が行えます。 メリット: セキュリティポリシーに沿ったアクセス管理が可能で、コンプライアンス要件にも対応できます。 ユースケース: 大規模な開発チームや、セキュリティが厳しい業界でのKubernetes運用に最適です。 4. CICDと統合しやすい Rancherは、CI/CDツール（例：Jenkins、GitLab CI、ArgoCDなど）との統合が容易です。デプロイメントの自動化や、アプリケーションのライフサイクル管理を効率化できます。 開発者にとってのメリット: 新しいコードのデプロイがスムーズになり、継続的なデリバリーが実現します。 ユースケース: DevOps環境の整備を目指す企業や、継続的なデプロイメントが求められるプロジェクトに適しています。 5. 高可用性とスケーラビリティ Rancherは、高可用性構成が可能で、障害が発生しても運用を続けられる設計です。Rancher自体を複数のノードで構成することで、障害に強く、スケールアウトに対応します。 メリット: クラスタのダウンタイムを最小限に抑えつつ、リソースのスケールを容易に実現できます。 ユースケース: ミッションクリティカルなアプリケーションを運用する企業にとって、信頼性の高いプラットフォームとして役立ちます。 6. プラグインとカスタマイズ性 Rancherは、さまざまなプラグインやカスタム設定をサポートし、個々のニーズに合わせた柔軟な運用が可能です。HelmチャートやYAMLファイルを用いたカスタマイズも簡単に行えます。 メリット: Kubernetesエコシステムとの互換性が高く、ユーザーのニーズに合わせて拡張可能です。 ユースケース: 特定のワークロードやビジネス要件に応じたカスタマイズが必要な場合に適しています。   Rancher導入のメリット オペレーションの効率化: マルチクラウドやハイブリッドクラウド環境での一元管理により、オペレーションの手間を大幅に軽減。 セキュリティの向上: RBAC機能やセキュリティポリシーの統合で、安全なクラスタ運用が可能。 コスト削減: 管理工数の削減と最適化されたリソース管理により、インフラコストを効率的に削減。   まとめ Rancherは、Kubernetesクラスタを簡単に管理できるだけでなく、マルチクラウド対応、直感的なUI、強化されたセキュリティ機能など、商用環境でのKubernetes運用を最適化する数々のメリットを提供します。Kubernetesの複雑さに悩む運用者にとって、Rancherは心強いツールとなるはずです。 また、OSSのRancherを商用環境で導入するための、エンタープライズサポートなどもSUSE社などから提供されています。OSS単体での導入は難しい場合などでもこれらのサポートを基に検討してみてはいかがでしょうか。 今後も数回に渡りRancherに関する技術ブログを執筆予定です。 今回は初回のため概要レベルからの特徴を説明しましたが、次回以降は実際の構築時のポイントやマルチクラウドでの利用ポイントをまとめていきますので是非見ていただければ幸いです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Rancher入門：マルチクラウド対応のKubernetes管理ツールとは？ first appeared on SIOS Tech. Lab .