サーバー監視 SaaS である Mackerel の OpenTelemetry 対応の一環として、ラベルつきのメトリックを自在に引くための PromQL エンジンを開発しました。PromQL は Prometheus というオープンソースの監視ソフトウェアで使われているクエリ言語です。
新卒エンジニアが初めて携わったこの大型開発の裏側とそこから得た学びを共有します。リリース10年目を目前にする SaaS に、 OSS に依存する大きな機能追加を行うエンジニアリングをみなさまにも追体験していただきます。
こんなことを話します:
私の所属する会社では、長年 Perl を用いた開発を行ってきました。
ここ数年で Go言語 への移行を進めていますが、大量にある Perl 資産を即座に全てGoに移行することは出来ず、並行運用しながらサービスの開発を行っています。
並行運用を行うということは、それだけ運用コストが発生します。
弊社のある試算では Perl のコードを全て Go に移行しきるまでに約 10年 の期間を要するのではないかと出ており、ここまでの長期間の保守を行うことは困難さがあります。
そこで、Perl から Go の移行を加速するための、Perl XS と Cgo を用いた Go の連携や、モダンなコンテナ環境、モダンなデプロイフローの構築など
Go への移行を円滑に行えるように取り組んでいる内容をお話します。
みなさんは15年以上動き続けるPerlのアプリケーションを見たことはあるでしょうか。私の周りには、数は減りましたが、そのようなアプリケーションがたくさんあります。その多くは積極開発フェーズではなく、いわゆるメンテナンスフェーズという状態です。
このようなアプリケーションでは、例えばそれぞれのフレームワークが違うとか、最初に書いた人の個性が大いに現れているとか、同じアプリケーションでも、いわゆる"雰囲気"が違うなど、一言では言い表せないような、様々な状態になっています。
積極開発されていないため、このような状態はもしかしたら「荒れ地」に見えるかもしれません。しかし、メンテナンスフェーズにあるからこそ、見えてくることもあるのではないでしょうか。
この発表では、古いPerlアプリケーションを運用する経験において、私が考えていることを整理し、Perlに限らない提言としてお話します。
2023年のYAPC::KyotoではChatGPT(LLM)がホットなトピックとして盛り上がった印象です。
Web API経由で使え、文章生成や要約をさまざまなWebアプリケーションに追加できます。
LLMから望む出力を得るにはプロンプト(例:以下の文章を要約してください)が重要です。
一方、開発を進める中で精度改善を狙ってプロンプトは変更されます。
では、プロンプトの変更前後でLLMが生成する文が同じなのかどうか、どのように評価すればよいでしょうか。
このトークでは文章の定性評価の評価指標を紹介していきます。
Pythonにそれぞれのライブラリがあるのですが、ROUGEやBLEUはPerlのスクリプトがベースという点が興味深く、YAPCでの発表のモチベーションとなっています
SonikはJavaScriptの「メタ」フレームワークです。メタというのは以下の3つの技術の上に成り立っているからです。
Sonikを使うことにより2つのことができます。
特にSonikは、バンドルサイズが小さく、レンダリングが高速で、Cloudflare PagesやVercelなどのエッジ環境に適しています。またDXも優れていて、CloudflareのBindingsに対応した高速な開発サーバーを備えています。
現在「アルファ」ステータスですが、当日は完成度の高いものを見せれると思います。
1993年にまつもとゆきひろ氏によって開発されたプログラミング言語Rubyは、Perl, Smalltalk, LISPなどの影響を受けながらも独自の魅力を持ち、日本をはじめ世界で利用されています。
私はこの10年Rubyを使い続けてきましたし、今後も使い続けるつもりでいます。このように「Rubyに対してお客様以上の気持ちを持っているプログラマーのこと」をRubyistといいますが、その意味で私はRubyistです。RubyにRubyの何が私を惹き付けるのか。このトークは以下の内容で構成されています。
経済産業省作成のレポートによると、パブリッククラウドの利用料を中心とする「デジタル赤字」は2030年には8兆円を超えるともいわれています。
円安も続くいま、クラウドコストの「最適化」に留まらず、より強気な「削減」を行わざるを得なくなることも予想されます。
今回は、私たちがコスト削減代行を100社以上行ってきたノウハウをもとに、
きれいごとではなく、何が何でも1ドルでも減らすための活きた「ケモノ道」的テクニックを紹介します。
※あらゆるパブリッククラウドに通ずることについて発表したいとは思っていますが、事例はAWSに関するものになります。
PostgreSQLで素朴に全文検索をする場合、LIKE演算子を使った中間一致になります。
デフォルトのPostgreSQLでは、LIKE演算子を使った中間一致検索にはインデックスを使用できないため、データ量に比例して検索速度は低速になります。
PGroonga(ぴーじーるんが)は、全言語対応の高速な全文検索機能をPostgreSQLで使えるようにする拡張です。
PGroongaでは、英数字も日本語等のマルチバイト文字に対してもインデックスを使った全文検索が可能です。検索速度は非常に高速で、かつ高機能です。
本発表では、PGroongaがどのくらい速いのか、どのような便利機能を持っているのかを紹介します。
本発表は、PGroongaのことをまだ知らない or PGroongaに興味はある(聞いたことはある)が詳しいことはしらない人 or 高速に全文検索したい人向けの発表です。
twitter(X)に何かあるたびに話題になるmastodonやmisskeyのような非中央集権型マイクロブログサービスが構成するネットワークは"fediverse"と呼ばれます。これらは主にActivityPubというプロトコルで接続されていますが、ActivityPub仕様は大枠を定めているだけであり、実際に現在のfediverseに参加するには単にプロトコルの仕様書に書かれていること以上のノウハウが必要になります。
このトークでは、Perl版ActivityPubサーバ"Actub"を紹介しながら、fediverseに参加するサーバアプリを作成するために必要なノウハウについて概説します。
内容としては、Builderscon 2019で発表したものをベースとして、Perlでの実装方法と、その後のfediverse界隈の変化に対応した最新の状況についてお話しします。
Goは並行処理で知られていますが、アクターモデルを導入することで、
さらに洗練された並行処理ができるようになります。
このセッションでは、アクターモデルの基本的な考え方とGoで実装する際の具体的な手法と効果、
実際の導入例をもとに詳しく解説します。
メッセージベースのコミュニケーションを中心としたアクターモデルが耐障害性や拡張性にどのような影響をもたらすのか、
EIPについてやProtoActor、Ergoといったツールキットも交えてお話しします。
Goとアクターモデルの組み合わせによるすこしだけ違うプログラミングパラダイムを探求してみましょう!
言語を問わず利用できるEvent SourcingはCQRSとの組み合わせだけでなく、そのエッセンスは様々な仕組みに取り入れることができます。
マイクロサービスアーキテクチャ化、大規模なデータ処理の改善、CDC、
分散システム・リアクティブシステム構築などではほぼ必須のテクニックとなっています。
しかし、ネット上にある記事を鵜呑みにしてしまうと致命的なアンチパターンに繋がってしまうことも多くあります。
状態をもたせないイベントでマテリアライズドビュー化してしまう、
巨大なランタイムを持たせてしまったハンドラ、
分割しすぎて時系列を無視したイベントなどなど。
当然いくつかは実際にやってしまったこともありますが、
このセッションでは実体験をもとにEvent Sourcingとは何かを説明しながら、
何をすべきでやるべきでないのかを楽しくお話します!
私は、今年で9周年を迎えたソーシャルゲームのサーバの保守・運用に従事しています。今回は、既存のサービスに対して新しい取り組みを行う模索として、Perlで動いているサーバに対してAPI通信を行ない、クライアントとして振る舞うプログラムをGoで書いてみるという挑戦をしました。このような挑戦をするに至った経緯や、ぶち当たった壁・それを通して感じたことなどをお話できたらと思います
話すこと
キャッシュはパフォーマンスを劇的に改善する効果がある反面、一度使うと簡単にはやめられない複雑性と中毒性があります。
その特性から「キャッシュは麻薬」と言われ、安易な利用は忌避されています。
しかし、キャッシュがもたらすパフォーマンスの改善効果は無視することはできず、コンピュータの世界において有効活用されているのも事実です。
そこで今回は実際にキャッシュを使う時に陥りやすい問題を取り上げながら、実際の活用例を説明します。
このトークでは、私が実務でイチからバックエンドアプリケーションを開発する際に実践している手法について紹介します。
近頃私はTypeScriptでバックエンドAPIを開発していますが、今回はPerlで簡単な事例を作って解説する予定です。
決して真新しい内容ではないでしょうが、この技術選択をした背景と理由を交えたトークにします。
対象者 中級者~上級者向け
話すこと
深く話さないこと
サブタイトル:「キャッシュは麻薬」という標語からの脱却
キャッシュは適切に使えば強い味方ですが、使い方を間違えると自分の足を撃ち抜くこともできます。まったく使わないと決めるのも、データ量やトラフィックのある Web アプリケーションでは不可能でしょう。
この発表では、キャッシュをパターン化し、各パターンにおいて、何を解決するのか、どういう実装になるのか、どんな落とし穴があるのか、を整理します。
「キャッシュは麻薬」として腫れ物を触るように扱うのではなく、自信を持ってキャッシュと付き合っていきましょう。
YAPC::Kansai 2017 OSAKA での @moznion さんのトークを本歌取りする発表です。
https://speakerdeck.com/moznion/pattern-and-strategy-of-web-application-caching
YAPCのPは任意のP。みなさんは何かしらのVM(Virtual Machine)を作ったことがあるでしょうか。私自身は過去にPHPでJVM(Java Virtual Machine)を作ったことがあります。現職はRuby on Railsがメインの企業です。PHPを主にやってきた私がRubyの気持ちを理解するにはひと工夫必要だと考えました。そこで,過去にPHPでJVMを作ったことがある経験を活かし,RubyVMを自作してRubyの気持ちを理解し学習速度を加速させようという考えに至りました。本トークではPHPでどのようにVMというものを作るのか,そしてRubyVMはどのように作っていくのかを,初心者でも「ちょっとわかったかも」と思えてもらうことをゴールとして解説します。もちろんPHPで実装できるということはPerlでも実装可能です。もし興味を持たれたらぜひPerlで実装してみてください。
カンファレンスや勉強会に参加して感動したり、あなたの人生を変えるような何かに出会ったことありますか?
あなたが好きだと感じたその場所が、いつか衰退して永久に失われてしまったら悲しいですよね。
しかしあなたは自身の"LIKE"を守るためいつでも行動をおこすことができます。
このセッションでは、コミュニティ運営を事例にして、自身が成し遂げたいと思った"LIKE"を実現に導くための道のりを紐解きます。
私が複数コミュニティを運営するなかでどんな困難を感じてどう乗り越えてきたかなどの経験を踏まえながら、何かを始めたり継続するために必要なマインドや行動のエッセンシャルをお伝えします。