matobaの備忘録

とあるエンジニアのブログ。技術に関連する活動やトピック多め

OpenTelemetry初心者のための前提知識

お疲れ様です。今日は「なぜOpenTelemetryが必要なのか」について私の理解をお話したいと思います。私はOpenTelemetryを実際に利用しているわけではありません。

先日、PyCon APAC 2023に参加し、山口能迪さんの「Pythonアプリケーションのオブザーバビリティ強化」の発表を聞いたり、発表後に質問をしたりして理解が深まったため、この記事を書いています。なので、もし勘違いや間違いが含まれていれば、教えていただけるとありがたいです。

www.youtube.com

OpenTelemetryの必要性がわからない私

さて、まず、この記事を書いてる私の状況から話をします。どうでも良い人はこのセクションを飛ばしてください。

OpenTelemetryの登場背景がわからない

OpenTelemetryについてですが、単語自体は数年前から聞いたことがありました。しかし、私は「これをいつ導入するのか」「何の目的で導入するのか」がよくわかっていませんでした。オブザーバビリティを高める、つまりシステムの状態を把握しやすくすることが重要だというのは理解しています。でも、以前は「なぜ、システムの状態が把握しにくい状況が起きるのか」「どういう状況から必要性が出てきてるのか」 「OpenTelemetryがなければどうなるのか」という点がわかりませんでした。なぜ、OpenTelemetryという技術が登場し、今に至っているのかの背景がうまく理解できていませんでした。

それがようやく理解できたので、今回の記事に至っています。

モノリス中心の開発現場が多かった

で「なぜ、私がわからなかったのか」というと「私はモノリスのアプリケーションに関わることが多かったから」でした。これまで関わってきたシステムやサービスで、複数サービスやプロセスが連携するものはありました。ただ、最近はモノリスのアプリケーションを作ったり、小規模なサービスを立ち上げに関わることが増えています。気づけば分散システムに関わったのは片手で数えられないくらい前になりました。

モノリスのアプリケーション開発現場において、アプリケーションの保守や運営、追加開発においては、「オブザーバビリティ」は高めやすい状況になります。なぜなら、ほとんどのコードが一つのリポジトリの中にあることも多いですし、ライブラリや外部のサービスを利用していても、機能の少なさから依存関係がわかりやすかったりします。言語の数も多くないですし、また、Sentryを使っているとトレーサビリティも高めやすいように思います。Djangoを使っている場合は、django-debug-toolbarやdjango-silkのようなデバッグ用のトレースモジュールもあります。

オブザーバビリティが下がりやすい状況

マイクロサービスとオブザーバビリティ

では、オブザーバビリティが低くなりやすい、または高めにくい状況って何でしょうか。多数のマイクロサービスで構成されているサービスが、そのような状況に陥りやすいように思います。最近、私もマイクロサービスについて考える機会が増えたことでこの課題、システム全体の状態、つまりオブザーバビリティに関心が向き始めています。

オブザーバビリティに関連して、「マイクロサービスがなぜ導入されるのか」についても簡単に触れます。前提として、モノリスは1人当たりの生産性が高く、エンジニアが少数の場合は有効です。特に素早く市場に投入し、ユーザーに価値を提供して実際にそのサービスが求められているかを検証したい段階では、モノリスが選択されることに特に疑問がありません。

開発速度の向上とオブザーバビリティの課題

しかし、ユーザーに求められていることがわかった場合や、テストがうまくいった段階で、多くの人に関わってもらいながら、1人当たりの生産性をなるべく下げずに全体の開発速度を上げたいという考えや属人性を排除したいという考えが高まります。他にも部分的に新しい技術を採用したいという話も出てきます。

このような流れから、マイクロサービスとして機能や責任を分解しながら大きなサービスを作っていくことが検討されます。この考え方や流れは、書籍「プロダクションレディ マイクロサービス」でも触れられております。

マイクロサービスを導入するメリットはありますが、それによる課題も生まれます。例えば、ログやレポートがバラバラの場所に保存されてしまって探すのが大変になったり、特定のサービスで何か問題が発生した際に、全体で何が起こっているのか、どの機能に影響があるのかがすぐには把握できない状況になったり。このような状況では障害の原因調査が難しくなります。つまり、サービス全体の「オブザーバビリティ」が低くなります。

オブザーバビリティ低下対策のはじめの一歩

「オブザーバビリティが低い状態」は、本当に困りますよね。ユーザーに対してサービスを提供している場合、ユーザーに何がどんな影響を与えているのか、何がうまく利用できていないのかを迅速に把握して、次の行動に素早く移りたいわけです。オブザーバビリティが低いと、状況把握が難しくなり、対応方針の検討や対策を誤る可能性が高くなったり、障害対応に時間がかかっていくわけです。それは困ります。

データをしっかり保存する

このような状況を解決するための第一歩は、きちんとログを取って、データをしっかり集めるところから始めるわけです。これは、マイクロサービスに限った話ではないんですが、実際には様々なツッコミどころのあるログに遭遇することもあるわけです。私も昔やりまして、様々な経験や指導を経て今に至っている訳ですが、これは基本中の基本なので、まずデータをちゃんと出して記録する必要があります。そういえば、先日参加したDjango Congress JP 2023でもそんな話を聞いたので紹介しておきます。

docs.google.com

他にもメトリクスを集めるというのも重要です。データを保存するところからオブザーバビリティの改善が始まる訳です。

オブザーバビリティを高める第二ステップ

データを一箇所に集めて見やすくする

さっき言ったようにオブザーバビリティを高めるためには、まず「ログやメトリクスをしっかり取る」ことから始めるわけです。それが一通りできたとすると、次の課題はデータ管理に移ります。特に古いシステムでは、ログがいろいろなディレクトリに散らばっていたり、複数台のサーバーを一つ一つ手作業で確認しないといけない状況がありますよね。これは流石に辛すぎるので、AWSのCloudWatch LoggingやGoogleのCloud Loggingなどを使って、データを一箇所に集めて、ブラウザから閲覧できるようにする訳です。コンテナで運用する場合は、最初から一箇所に集めたりしますね。

サービスごとにデータ管理が異なる課題

ただ、そこから別の問題が出てきます。サービスごとにログやメトリクスの集約場所や方法が異なるケースが多々あるのです。そうような場合、障害調査も「このデータはどこにあるの?」とか「どうやって見るの?」といった基本的な問題から始まってしまいます。さらに、いろいろなサービスが絡むと、どのデータを集めているのかも曖昧になってくる。この問題は、マイクロサービスになるほど深刻になっていきます。

結果として、障害調査が特別なノウハウの必要な状況になってしまいます。なので、全体を知っている人がいないとなかなか状況が把握できず困った状況になります。これはよくない状況ですね。

ここまで来てようやく OpenTelemetoryという概念が重要になります。

高いオブザーバビリティを維持するためのOpenTelemetry

OpenTelemetoryの話に移ると、まず、山口さんの発表がOpenTelemetoryを理解する近道になると思います。私はまだ手を動かしていないため、その前提で聞いてください。

OpenTelemetryを簡単に

簡単に言えば、OpenTelemetryは、ログやメトリクスなどを取得して貯めるための標準的なフレームワークです。これを使えば、いろんなサービスのデータを一箇所で集約しやすくなります。そして、これはオープンな仕組みであるため、特定のベンターにロックされるのを防ぐ効果もあります。

opentelemetry.io

OpenTelemetryの嬉しい点

OpenTelemetoryの考え方としては、このデータを一箇所に集めます。その場所がOpenTelemetry Collectorと呼ばれます。そして、それを閲覧するUIのサービスとして様々なものを利用できるようになります。つまり、データの保存場所をOpenTelemetryにして、各種サービスではなくせるということです。

ここにデモのアーキテクチャの図が存在しているので、ここのデータフローを見るとわかりやすいです。

opentelemetry.io

集めたデータは、具体的にどこで見れるの?というと、UIとしてこのようなベンダーが提供してるサービスが使えるようです。(画面までは具体的に見れてません)

opentelemetry.io

OpenTelemetryの課題と解決策

ただ、OpenTelemetoryを利用する際の問題もあるそうですね。それはOpenTelemetoryは設定もドキュメントも多くて、何をどう設定するのが良いか把握するのが難しいことらしいです。その問題を解決するために、自動計装という解決策が出てきたそうです。これを紹介するのが、 PyConAPACでの山口さんの発表でした。

実は私自身、まだ実際に手を動かしていないので、詳細は山口さんの発表を聞いてください。以下にリンクを貼っておきます。

www.youtube.com

まとめ

サービスが分散していると、その都度ダッシュボードが違ったり、何をどこで取っているのかすらわからなくなり、システムの状態把握が難しくなりますよね。こういう状況を改善する際の一つの方法がOpenTelemetryの利用です。信頼性はユーザー目線で考えるべきで、全体の品質をどう担保するか、それには「SRE」(Site Reliability Engineering)という考え方が関わってきます。そして、それを維持していくために特定のベンダーに依存するのは望ましくありません。その考え方に関連する概念がOpenTelemetryであると理解しました。

PyCon APACでの発表を聞くことで、これまでに読んできた本や様々な経験から色々と学んでいた内容の点と点がつながった感じがします。だから、この経験と理解をブログにまとめておきました。同じようなことを考えている人もいるかもしれないですからね。

今後は、実際にOpenTelemetryを触ってみたり、山口さんが紹介されてた書籍を読んでみたいと思います。

この記事が誰かの参考になれば幸いです。

Maker Faire Tokyo 2023に参加してきました

こんにちは、お疲れ様です。今回は、MakerFaire Tokyo 2023というイベントに参加してきた話を書きたいの思います。あまり時間がないので、言いたいことはたくさんあるのですが、今回は短めにしておきます。なお、出展側ではなく、一般参加者です。

Maker Faire Tokyo 2023
Maker Faire Tokyo 2023

続きを読む

情報流通という概念が面白いと感じた話

今日もお疲れ様です。ブログは一回更新すると、なんとなく更新のハードルが下がる気がするmtbです。今日もブログを更新しようかなと考えています。

今日のテーマときっかけ

今日のテーマは、"情報の流通"という概念についてです。正直、この概念について、今まであまり考えたことはありませんでした。でも、この概念が本当に面白いと思ったので、その魅力やなぜ面白いと感じたのかについて話してみようと思います。

なぜ「情報の流通」が面白いか

なぜ「情報の流通」が面白いと感じたのか、その理由は多分、私が地方出身だからかもしれません。私は中高生の頃、知りたいことや興味のあることがたくさんありました。そして自分でも調べようとしていました。でも、「どの本に書いてあるのか」「何と呼ばれているのか」「どこで調べればいいのか」といった基本的なことまで気づくのに時間がかかりました。結局、違う場所を調べていたり、後で「あ、この概念があったのか」とか「この本があったら早く教えて!」といったことを後から知ることが多かったんですよね。

私はそういった問題をどう解決するかと考えていました。その問題の解決にブログやイベントは貢献すると思っていて、何らか貢献したいとも思っていました。それらの目的は、「情報の流通を活性化する」というフレーズで集約されるんだな、と思いました。このように今まではまとまりがなかった活動や概念を一つに束ねる言葉が見つかったから、私はそれが面白いと感じたんだと思います。

きっかけは、昨日のDjangoCongress JP

blog.mtb-production.info

昨日のDjangoCongress JP 2023です。そこのLTから「情報の流通」という概念を得ました。LTの中で、コミュニティやブログが「駅」のようなもので、開催や更新によって情報が流れていくという話がありました。この「コミュニティやブログは駅」というメタフォーがかなり印象的でした。

それから人々がその情報を特に気にせず通り過ぎても、それだけで情報が流れるというのは、とても意味のある考え方だと思っています。この「駅」のメタフォーが、情報の流通とは何であり、何が重要かをシンプルに表現していると感じて、多くの考察がしたくなりました。

メタファーの考察と自分がやりたいこと

じゃあカンファレンスは何?

例えば、コミュニティやブログが駅のようなものという話から派生させて考えていると、「じゃあカンファレンスはターミナル駅のようなものかな?」と思ったり。カンファレンスにはいろんなタイミングで、さまざまな業界の人々が集まります。そこで起きるのは、新しい出会いや知識と情報の交換です。

最寄りの小さな駅、つまり小さな勉強会やブログから、大きなターミナル駅であるカンファレンスを知るわけですよね。そしてそのカンファレンス、その大きなターミナル駅に行って、そこから別の勉強会やブログ、コミュニティに進む。こんな流れが現実に起きていると感じます。

私自身もそうで、ある小さな勉強会からカンファレンスを知り、そのカンファレンスに参加してから、別の勉強会やコミュニティに移動した経験があります。このような情報の流れと人々の移動は、まさに駅と線路のような存在なんだなと感じています。

そして、このように行き来が自由な「カンファレンス」という場は、その価値が確かにあり、カンファレンスと勉強会やブログの関係、その価値をイメージ化するというのは、とても面白い作業だと感じています。

私も「最寄駅」を作りたい

また、例えば、私も一つの「最寄駅」を作りたいと思います。昨日のイベントの発表の中でもありましたが、初心者がいきなり技術的なカンファレンスに参加するのはハードルが高いわけです。でも、自分が関係のある特定技術やコンテンツに関連する小さな勉強会なら、参加のハードルは低くなります。

一度そういった勉強会に参加してみると、「意外と大丈夫かも」と思い始めます。そこから、「あの人がおすすめするカンファレンスや勉強会にも行ってみよう」という流れが生まれるように思うのです。私もこのような情報と人々の流れを作る一つの乗り場、となる最寄駅が作れたらいいな、と考えています。

情報を運ぶ"列車"にもなりたい

私は情報を運ぶ"列車"にもなりたいと考えているのがわかりました。つまり、私がいろんな場所で得た知識を、自分が関わっているコミュニティやブログの読者にも伝えていきたいというわけです。その場所は、コミュニティやブログかもしれませんし、書籍や自身の経験かもしれません。

このような役割を果たすためには、まず私自身が多様な場所に足を運び、さまざまな人と対話し、多くの情報を吸収する必要があります。それだけでなく、得た情報を積極的に言語化し、コミュニティやブログなどで積極的に発信していく必要があります。要するに、いわゆる「伝達」の役割も担っていきたいと考えたりします。

また、当然ですが、誰かに運ばれるような情報自体も創造していきたいですね。いろんな経験をした上で、新しい概念や価値を見つけて、その理由や目的を整理し、言語化していく。これが情報の創出に繋がると考えています。そして、情報の簡単な発表の場として、自分のブログは使えるとも感じています。ブログを書く行為を通して、私が持つ情報を下車させ、別の列車に乗せてもらう感覚です。

他の色々な考察

他にもいろいろ考えて見ました。ブログを立ち上げたり、コミュニティを作る行為は、まるで駅を作るようなものだとイメージすると、駅をどんな駅にするか、どんな路線で作るかは、集まりをどんなテーマやカテゴリとして作るか、どんな形式によって決まるのか?と想像したりもしました。それによって多様な路線に変わる余地もあるし、利用者(参加者)がいなくて廃止される可能性もあります。運用を維持するコストが高いと判断されれば、その線路はなくなってしまいます。

例えば、私が興味を持っているテーマは、多岐にわたっています。例えば、育児と仕事の両立に関する技術やプロダクト、自分が住んでいる地域に関わる技術、または私の故郷である和歌山に関連するエンジニアのコミュニティなど。他にも、なんとなくレベルでは、技術トピックとしては、音楽やサウンド、組み込み開発、情報教育なども興味があります。この雑多なイメージから、自分が何を作って何を作らず、何には参加して、何に参加させてもらうのか、そして何が現実的なのだろうか、とか今はまだ考えは整理されていません。

このようなメタファーを通じて、コミュニティ運営についても考えて見たりしました。現時点ではなんとなく「自分も何かしらのコミュニティを立ち上げて運営したい」という漠然とした気持ちだけで、そのさきの具体的なものは考えられていないのですが、何かを始めるなら、しっかりと続けて、価値のあるものにしたいとは思います。時間の限界もあるので、一気に全てはできないのですが、その関係で気が向いた時に「コミュニティとは何か」という基本的な問いについて、考えることがあります。

終わり

そんなことを考えつつ、情報流通やコミュニティについて考えた1日でした。気が向いたら、これからもこのようなブログや情報発信を続けていきたいと感じています。最後まで読んでいただき、ありがとうございました。

DjangoCongress JP 2023に参加してきました

はい、こんばんは、お疲れ様です。本日、DjangoCongress JP 2023に参加してきました。ここではその体験をレポートとして共有したいと思います。

djangocongress.jp

久しぶりのオフラインイベント

まず、イベントでは同僚に結構お会いしました。皆さん、お疲れ様です。久しぶりに顔を合わせることができて嬉しかったです。リモートワークが中心の今、なかなか会えない人もいたので、新しい顔を見る機会もありました。他にも、今日のイベントだから初めてお会いする方もいて、とても良い時間でした。ありがとうございます。

印象に残った発表

印象に残った発表についても話したいと思います。なお、今回は同僚からの発表は省略します。

スライドはサクッと見つかったもののみ貼ってます。(教えてくれると張ります)

グラフデータベースを用いたDjangoアプリ作成入門

まず、一つが、Neo4Jに関する発表です。これはグラフデータベースについてのセッションでした。正直、グラフデータベースという言葉自体は以前から知っていましたが、どう使うのか、ハードルが高いと感じていて、ちょっと敬遠していました。

しかし、この発表で「ああ、こんなふうに使うのか」というイメージが湧きました。特に、DjangoとNeo4Jを連携させる「django-neomodel」というライブラリについて知れたのは非常に有益でした。

帰り道の電車の中では、ChatGPTを使って、Neo4Jやグラフデータベースで何ができるのか整理したり、思いつくアイデアを仮実装させてみたりしていました。この発表は私にとってかなり有意義でした。

Django初心者が中級者になるために知るべきこと

次に、中級者になるための話ですね。発表の中であった"知識のインデックスを作る"のが重要という点は、特に興味を引かれました。ChatGPTなどがある時代において、その価値について詳しく話していた部分は、面白かったです。私自身も、今の時代においては、このような「インデックス」が非常に重要で、価値が高いと思います。なので、現在の状況や時代背景を反映しているように感じて、それが良いな、と感じて聞いていました。

あと、設計はモデルから先に考える話は興味深いと思いました。漠然と、そうしていたことを言語化して改めて教えてもらった感じがしました。

Django migrationsで学ぶデータベース設計

次に、Djangoのマイグレーションとデータベース設計に関する話です。このセッションもかなり面白いものでした。マイグレーションの種類や、その実行時に、データベースで具体的に何が起きているのか、というテーマは私も気になっていて調べたいと思っていました。 その点について説明されていたので、非常にありがたいと思いました。自分で情報を探しそうとすると、何から手を付けるべきか迷いそうだったのですが、この発表でその輪郭が見えた感じがしました。また、正規化の視点とユースケース駆動開発からの視点でデータベース設計の話をしていて、それも面白いと思いました。

とみおさんのLT

www.docswell.com

続いては、サイボウズとみおさんのLTです。テーマは勉強会やコミュニティ、そして情報流通についてでした。この話題には個人的にも興味があって、ちょうど最近、コミュニティの立ち上げや勉強会の企画、情報発信について改めて考えていたので、非常にタイムリーでした。

特に、「コミュニティや情報発信は、コンテンツがハブになり、そのハブが情報流通を活性化させる」という話が印象的でした。そして、「コミュニティは、ただ参加するだけでも、コミュニティやイベントの維持に貢献している」という話もあり、それは非常に共感しました。正直、このような話をDjangoのイベントで聞けるとは思っていなかったので、とてもいい出会いだと感じました。

終わり

久しぶりのオフラインイベントへの参加でしたが、いろいろと予想外の出来事もありました。やっぱり、オフラインのイベントはいいなと思える体験でした。参加者の皆様、お疲れ様です。そして、スタッフの皆様、発表者の皆様、ありがとうございました。

イベントの参加後の余韻が残るうちに感想をブログに書きたいと思い、即日ですが書きました。実は、帰り道の電車でアウトラインを書き、帰宅後に、音声で入力して、それをChatGPTに校正させてます。なので、文章が微妙にChatGPTっぽいですが、それはご容赦ください。

今日はこれで終わりにしようと思います。ありがとうございました。

Pythonで文字列からURLを抽出したい時に使えるライブラリ

Pythonで文字列からURLを抽出したいなあ。でも正規表現を書くのは嫌だなあ。という気持ちになりました。

ライブラリ探したら見つかった&日本語記事だと正規表現ばかり紹介されていたので、書いておきますね。

github.com

Welcome to urlextract’s documentation! — urlextract 1.8.0 documentation

インストール

pip install urlextract

使ってみる

>>> from urlextract import URLExtract
>>> extractor = URLExtract()
>>> text = "Pythonで文字列からURLを抽出したい時に使えるライブラリを探していたら、 https://github.com/lipoja/URLExtract が見つかりました。"
>>> urls = extractor.find_urls(text)
>>> print(urls)
['https://github.com/lipoja/URLExtract']

余談

ちなみにライブラリは、 Pythonで文字列からURLを抽出したいけど、正規表現書きたくない。いい感じのライブラリありますか? みたいな雑な問をChatGPTに聞いたら出てきました。

雰囲気だけ知りたい人のための「LangChain」の話

最近、ChatGPTのような技術を関連する情報を見てると、LangChainと呼ばれる技術を見聞きするようになりました。

今回は、「LangChainとは何か」「LangChainを使うと何ができるのか」といった話を軽く調べて整理していこうと思います。

私の場合、新しい技術を学ぶ際、最初は動かさずにドキュメントやコードを眺めて雰囲気を掴むのですが、今はその段階です。実際に動かしている人は勘違いしている内容にコメントもらえると喜びます。

本記事は見つかった記事を読みつつ、未来の自分に向けて現状の理解を整理したものになります。

LangChain とは

  • LangChainは、LLMを利用してサービスを開発したいときの便利ライブラリ
  • OpenAIが提供するAPIだけでもAIチャットサービスを開発できるが、開発中のよくある課題を解決するときに便利(らしい)

関連リンクです

LangChain の 便利なこと

  • LLMを使う時によく使う読み出しや読み込みのユーティリティが用意されている
  • LLMへのリクエスト(プロンプトと呼ばれる)のテンプレートを管理できる
  • 様々なLLMへのインターフェースを標準化できる。OpenAIのAPIからCohereやHugging Faceに切り替える、などができるらしい
  • LLMを組み合わせてアプリケーションを作るときの、枠組みを提供してくれる
  • LLMとの会話のやりとりをシリアライズする仕組みがある

疑問:よく使う外部呼び出しのユーティリティとは?

この辺にリストや用途があります。

Getting Started — 🦜🔗 LangChain 0.0.126

以下のような呼び出し先があります。

  • bing検索
  • Google検索
  • OpenWeatherMap
  • Wikipedia
  • Wolfram Alpha
  • Zapier

Zapierを呼び出せるってことは、Zapier経由で投稿できる全てがサクッと呼び出せてしまいそうですね。

また、Document Loaderという機能もありました。

Document Loaders — 🦜🔗 LangChain 0.0.126

これは既存のテキストデータをLLMと一緒に使う方法で、ここもたくさんのサービスを呼びだすユーティリティが用意されてるようです。ざっと見てると見たことがある名前がたくさんありました。以下は抜粋です。

  • Google Drive
  • Evernote
  • Notion
  • CSV
  • HTML
  • Email
  • Figma
  • Markdown
  • PDF
  • PowerPoint
  • ReadTheDocs Documentation

疑問:LLMってそんなにたくさんあるの?

この辺にリストがありました。

python.langchain.com

素人的には「たくさんあるなあ(語彙力)」という印象を受けました。

疑問:LLMとの会話のやりとりをシリアライズする仕組み?

サービスを開発しようとするをLLMとの会話の履歴をデータベースに保存したり、再読み込みしたり、ということが発生するのは予想できます。

会話履歴をPythonのdictのlistで出力できる&それを読み込めばオブジェクトを復元できるようですね。(試してないし、それで足りるのか不明ですが)

Getting Started — 🦜🔗 LangChain 0.0.126

終わり

私は、LangChainという名前をTwitterやイベントで見聞きしつつ、実際に触るようなまとまった時間を取れずに今に至ってました。とは言え、どういうものなのかは気になっていたので、ドキュメントや資料をざっと読んで情報を整理してみました。

今回は、雰囲気だけLangChainを調べました。せいぜい1hほどドキュメントや諸々を眺めた程度の知識ですが、読んだ方の1hを5minに圧縮できたら何よりです。

次は、実際に触ってみようと思います。(触った結果を記事にするかはその後の気分によります)

また、機会があれば、LangChainで何かしらの機能やサービスを開発してみたいですね。今回はこれで。

参考にしたページ