YAPC::Tokyo 2019 にカヤックのエンジニアが3名登壇します！ #yapcjapan

技術部の小池です。

いよいよ今週末に迫りました YAPC::Tokyo 2019、弊社からも3名登壇予定なのでご紹介させていただきます！

トーク内容をプロポーザルの抜粋にてご紹介します。いずれもカヤックの仕事から生まれたノウハウが詰まった内容となっています。

Perl5の静的解析入門　機械と人間双方の歩み寄りによる平和編

Room1 で 14:00 からです。

https://yapcjapan.org/2019tokyo/talks.html#/detail/2

"Only perl can parse Perl" という言葉にもあるように、長年Perlスクリプトをperlコマンド以外が解析し、利用することは難しいことであると思われてきました。もちろんPPI.pmやperlapiを利用するソリューションもいくつかはありましたが、Perlを静的解析するアプローチはこれまであまり活用されて来なかったように思えます（筆者の視野内の感想です）。

このトークでは、主にDamian Conway氏の作ったPerlスクリプトを正規表現で解析するPPR.pmを用いて、Perlスクリプトの静的解析を行う話をします。具体例を挙げると、昨今のモダンな言語のコンパイラやlinterが備えているような機能を実装します。また、人間が自由気ままにPerlスクリプトを書くと、機械が解析するのにも限界があります。他のプログラミング言語では人間側に型を書くことを強制させたり、その場で関数名を文字列で組み立てて呼び出しするのを禁止するなど、静的解析がしやすい言語デザインになっています。 Perlを書くときも安全安心なコードにするために静的解析を用いたい、そのためには人間側にも歩み寄りが必要です。このトークでは具体的な「静的解析がしやすいPerlスクリプトの書き方」についても提案します。

こんな人に聞いてもらいたい

Perlスクリプトを静的解析できないと思っている方

"Use of uninitialized value" に対抗できる魔術がないか探している方

静的解析という言葉はわからないが、なにか惹かれるものを感じる方

静的解析がしにくい例を通じていかにPerlが人間中心のプログラミング言語であるかを感じたい方

Perlでも分散トレーシングしたい！ - AWS::XRayによる解析とその実装

by fujiwara

ホールで 15:40 からです。

https://yapcjapan.org/2019tokyo/talks.html#/detail/3

皆さんマイクロサービスしてますか？

昨今のWebアプリケーションは、内部ネットワークにある DB や KVS へのクエリだけではなく、多数の外部サービスと通信する必要が増えてきています。外部への通信は往々にして不安定で、レイテンシやエラーの発生率も高いものです。

障害が発生した場合にその原因を追及したり、パフォーマンスに問題があるのでチューニングを行いたい場合には、これらの外部呼び出しの状況を可視化することが大変強力な手段になります。

AWS(Amazon Web Services) X-Ray は、外部リソースへの通信をモニタリングし、解析するためのマネージドサービスです。AWS 外で動作しているアプリケーションに対しても使用できます。残念ながら Perl 用の公式 SDK は提供されていないため、AWS::XRay 等のライブラリを実装し、CPAN で公開しました。

このトークでは、分散トレーシングの概要、AWS::XRay, Plack::Middleware::XRay による実際のアプリケーション(例として ISUCON8 本選の Perl 実装)を解析する手法、どのように AWS::XRay が実装されているかの解説を行います。

聞いてもらいたいかた

マイクロサービスやるぞ！というかた

Webアプリケーション(特に既存のPerl製のもの)のパフォーマンス解析がしたいかた

グラフを眺めてニヤニヤするのが好きなかた

Perl 用の SDK は提供されないことが多いけど頑張っていこう、というかた

AWS::XRay についてはこちらのブログにも記事があるので興味のある方はご覧ください。

sfujiwara.hatenablog.com

自前運用のZabbixからマネージド監視サービスMackerelへ - ソーシャルゲームタイトルのサーバ監視の移行事例

by suzuki

Room0 で 14:50 からです。

https://yapcjapan.org/2019tokyo/talks.html#/detail/39

弊社ではZabbixでサーバ監視を行ってきましたが、自前運用のZabbixサーバにかかる運用コストが問題になっていました。

この問題をマネージドなサーバ監視サービス Mackerel の導入によって解決しようとしています。

本トークではそれらの取組のうち、自社ソーシャルゲームタイトル「僕らの甲子園ポケット（以下ぼくポケ）」におけるZabbixからMackerelへのサーバ監視の移行事例について話をさせていただければと思います。

具体的には以下のような内容となる予定です

監視・メトリクスの移植

アラートではないが通知はほしいケースへの対処方法

Mackerelならではの便利な機能

オートスケールやプロビジョニングとmackerel-agentをうまく付き合わせるための工夫

本家のrepoへPRを送って積極的に改善していく

github.com/ryotarai/waker と連携したアラートエスカレーション

自作プラグイン・ツールを利用した柔軟な監視

サーバ以外の監視: アラート通知の変更を通知して誤操作に気づけるようにする

mackerelをservice discoveryとして活用して深刻な障害時に緊急メンテを入れる