RAG構築のためのAzure OpenAI Serviceリファレンスアーキテクチャ詳解/wakarimiragarchitecture

はじめに X.509 証明書について解説します。(English version is here → "Illustrated X.509 Certificate") ※ この記事は 2020 年 7 月 1 日にオンラインで開催された Authlete 社主催の『OAuth/OIDC 勉強会【クライアント認証編】』の一部を文書化したものです。勉強会の動画は公開しており、X.509 証明書については『#4 X.509 証明書（１）』と『#5 X.509 証明書（２）』で解説しているので、動画解説のほうがお好みであればそちらをご参照ください。 1. デジタル署名（前提知識） この記事を読んでいただくにあたり、デジタル署名に関する知識が必要となります。つまり、「秘密鍵を用いて生成された署名を公開鍵で検証することにより」、「対象データが改竄されていないこと」や「秘密鍵の保持者が確かに署名したこと

社内でKubernetesハンズオンをやってみたのでおすそ分け。 参加者6人からバンバン出てくる質問に答えながらやって、所要時間4時間ほどでした。 SpeakerDeckにも資料を上げています。 https://speakerdeck.com/ktam1219/yaruze-kuberneteshanzuon (2019/07/11追記) 続編書きました！ -> 今度はあんまりゴツくない！？「わりとゴツいKubernetesハンズオン」そのあとに ハンズオンの目標 Kubernetesとお友達になる イメージを掴む 触ってみる(ローカル・EKS・ちょっとGKE) 構築・運用ができるような気分になる 巷にあふれるKubernetesの記事・スライドが理解できるようになる EKSがメインになっているのは、会社の業務でAWSを使うことが多いからです。 純粋にKubernetesを勉強したいだけな

この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき

こんにちは、Stamp Incのnoriです。 金曜日の20時くらいからこの記事を書き始めて若干の後悔を感じながら記事を書きました。書き終わったら飲みに行きます。 この記事ではCloud FirestoreとFirebase Cloud Storageを使ってソーシャル機能を実装する方法を紹介します。 どの機能においてもですが、実装方法は要件と照らし合わせて考えることが重要です。ソーシャル機能も要件によって実装方法は異なってきます。要件によって実装がどう異なるかについても説明しようと思いますので最後まで読んで頂けると幸いです。 また、ここでのソーシャル機能とはフォロー、フォロワーに限定して話を進めます。 早速ですが、フォロー、フォロワーをCloud Firestoreではどのように表現するか見ていきましょう。 QueryとSubCollectionが利用可能なCloud Firestore

エンジニリング組織の作り方 @ Sansan Innovation Lab @yuuk1t / id:y_uuki https://sansan.connpass.com/event/125822/

こちらの記事は弊社技術ブログに掲載していた内容となります。一部を除き、投稿当時の情報となりますので、紹介内容の最新情報については別途公式情報等をご参照下さい。 こんにちは。クラウドエース編集部です。 コンプライアンスを把握する必要性 多くの企業や官公庁はオンプレミスの時代からデータセンターや SIer の選定などで ISO や PCI DSS を取得しているかどうかのチェックを行っています。本記事はメガクラウド（GCP / AWS / Azure）が独自監査を実施しているコンプライアンスを表でまとめています。オンプレミスからクラウドへの移行、クラウドからメガクラウドへの移行検討の際に参考にしてみてください。 オンプレミスからクラウドに移行する際には、様々な検討を重ねるのが通常です。検討する内容としては、クラウド上でのアーキテクチャ、スペック、コスト、セキュリティ、運用など、様々な項目があり

不正送金やアカウントの乗っ取りなど、パスワードが原因の事件が後を絶ちません。高齢者など、IT リテラシの低い人でも簡単かつ安全に自分のオンラインアカウントを管理できる世界が理想ですが、まずはパスワードの不要な世界を実現するのが先決であることは、これまでのインターネットの歴史で証明されたと言えるでしょう。そして、ここに来てパスワード不要なログインを実現する技術として注目されているのが FIDO (= Fast IDentity Online, 「ファイド」) です。そしてその FIDO をブラウザから利用できるようにするのが WebAuthn (= Web Authentication、「ウェブオースン」)。報道内容などからこれらは指紋認証を実現するもの、と思っている人もいらっしゃるかもしれませんが、実際にはちょっと違います。 WebAuthn に関しては、すでに数多くの記事が出ていますので

やりたいこと（ユースケース）から利用パターンへ到達できるように、ユースケース主導で紹介。利用するサービスのすべての機能をを覚えなくてもやりたいこと/部分からスタートできます。実際、類似するアーキテクチャの実例が多くあることがわかります。 パターン別のテンプレートから始めてみよう!  チュートリアルで体感しよう! - いくつかのパターンはテンプレート/雛形から始めることができます。それぞれのパターンの「Template」「Sample」「Solution」のリンク先を参照ください。 - 実際に作って動かせるチュートリアルに「Tutorial」「Workshop」リンクからアクセスできます。ちょっとしたトライに費用が気にならないのもサーバーレスの良いところ。 - 各パターンの特性に合わせたエラーハンドリングの記事を拡充中。それぞれのパターンの「エラーハンドリング」リンクからご確認ください。 -

こんにちは。メルペイで、決済・振込申請のバックエンドソフトウェアエンジニアをしている id:koemu です。 今日は、バッチ処理を行う理由について、考察を深めて設計に活かしていく話をしたいと思います。 はじめに バッチ処理とは、ある決まったタイミングで1つのプログラムが複数のデータを 一括処理 することを指します。この反対の言葉として、オンライン処理があります。オンライン処理とは、お客様の操作を初めとしたイベントをもとに 逐次処理 されるものです。OLTP(Online Transaction Processing)とも言います。 本エントリでは、バッチ処理を採用するにあたり、どういったユースケースが適切なのかを整理して、今後のソフトウェアの設計の指針にできることを目指しています。今回は、「バッチ処理を採用するとき」と「バッチ処理の設計」の2つについて取り上げます。 バッチ処理を採用する

こんにちは！アルのiOSアプリを開発している koogawa です。 さて皆さま、先日 Cloud Firestore からベータが外れ、利用できるリージョンが増えたのを覚えているでしょうか？ 新規に追加されたリージョンの中にはなんと Asia、つまり東京リージョンも含まれていたことで話題になりましたね。 アルも DB に Firestore を採用しており、今まではデフォルトの us-central リージョンを利用していました。そして、本日リリースした Ver. 1.9.1 からは asia-northeast1（東京リージョン）に移行しました！🎉 その結果、データの取得にかかる時間が大幅に改善されました。 以下、この記事では、既存のFirestoreプロジェクトを東京リージョンに移行する上で私達が得た知見などをまとめていきたいと思います。 前提- Firestoreのリージョンは

自宅に置いたラズパイ(つまり、NATの内側にあるのでインターネット側からは直接は見えないところにある。）を外からsshでログインできるようにしてみました。いろいろと応用できそうなので、ここに記録を残します。 概要 外からsshでログインできるクラウドの仮想マシンを用意して、それを経由してラズパイにアクセスできるようにします。 ラズパイが起動したら、そのクラウドの仮想マシンにSSHのトンネルを作るようにしておきます。 これで、いつでもクラウドの仮想マシンからラズパイにsshでログインできるようになります。 (気が向いたら図を描く) 準備 今回はクラウドの仮想マシンとしてAWSを使いました。 pemファイルでログインできるようにしておき、そのpemファイルをラズパイに置きます。 また、その仮想マシンのパブリックのIPアドレスは固定になるように設定しました。 ここではその仮想マシンをaws001

�これまで目指していた「変化に強いインフラ」の話から、Microservices における課題、インフラチームが目指すものの変化、それをどう解決していくか？という話をしました July Tech Festa 2018 at 産業技術大学院大学(公立大学法人 首都大学東京)

こんにちは。Backlog のSite Reliability Engineering (SRE) を担当している吉澤です。 AWS アクセスキーを含むコードを GitHub の公開リポジトリにプッシュしてしまい、そのアクセスキーがビットコインの採掘に使われて AWS から高額請求が来た！という話をたまに目にします。今年の2月に検証された方（GitHub に AWS キーペアを上げると抜かれるってほんと？？？試してみよー！)によると、git push から13分で不正利用開始されたらしいです。怖いですね……。 Backlog のソースコードは Backlog の提供する Git リポジトリで管理しています。Backlog の Git にはリポジトリの公開機能はないので、AWS アクセスキーをプッシュしたからといって即座に悪用される可能性は低いです。とはいえ、漏洩時の影響が大きいため、AWS

先日書いた AWS の勉強方法をまとめた記事（AWSを学ぶ上でやってよかった勉強法５選 - log4ketancho）で、「簡単なWebサービスをAWSで運営するといい勉強になるよー」と書きました。その中で、 今まで経験したり今いるところはどこもオンプレばかりでAWSとかのクラウドの知識が全くつかないからどこかで勉強したいし個人サービス運用とかしたいんだけど、1年過ぎるといきなりコストがドカンとかかりそうで…… や 「２）簡単なWebサービスをAWSで運営する」は誰もが考えることだが、最初の無料期間1年間以外、AWSで個人ブログなりを運用するのはコスト悪すぎだろ…。 というような利用料金が気になってしまう、、というコメントを幾つかいただきました。 この気持ちとても分かります！業務で使う分にはサーバー何台立てようが気になりませんが（は言い過ぎですがｗ）、個人でサービスを運営する場合はそうはい

クックパッドの新規サービスKomercoを設計した@1amageekです。 クックパッドの新規サービスKomercoはTechConfでも発表した通り全てサーバーレスで開発されています。サーバーレスの利点や開発におけるメリットはこの資料に説明しているので、今日はFirestoreについて深く説明したいと思います。また、Firestoreのざっくりした説明に関してはこちらをご覧下さい。 Cloud Firestoreは進化したFirebase Realtime Database Firebase RTDB + GCP datastore = Firestoreについて第一印象 FirestoreはSpannerと同じテクノロジー構築されている FirestoreはSpannerと同じテクノロジー構築されています。つまりSpannerの特性を理解することでFirestoreのコアを知ることが可

仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO

2018年1月3日にCPUに関連する3つの脆弱性情報が公開されました。報告者によるとこれらの脆弱性はMeltdown、Spectreと呼称されています。ここでは関連情報をまとめます。 脆弱性の概要 報告者が脆弱性情報を次の専用サイトで公開した。 Meltdown and Spectre (またはこちら) 3つの脆弱性の概要をまとめると次の通り。 脆弱性の名称 Meltdown Spectre CVE CVE-2017-5754（Rogue data cache load） CVE-2017-5753（Bounds check bypass） CVE-2017-5715（Branch target injection） 影響を受けるCPU Intel Intel、AMD、ARM CVSSv3 基本値 4.7(JPCERT/CC) 5.6(NIST) ←に同じ PoC 報告者非公開 論文中にx