Engineering(SRE)、ソフトウェア開発、クラウドコンピューティングなどについて、吉澤が調べたり試したことを書いていくブログです。2も参加してきました。1のレポートはこちらをどうぞ。2に聴講したセッションはこちら(↓)。ベストトーク賞(1日あたり2件、計4件投票できる)は、★付きの講演に投票しました。8月22日のLTクロージング全体通しての感想YAPCは今回初参加だったのですが、Perlは全然使ってない僕のような人間でも十分楽しめました。講演の採択率が非常に低いということもあって、どのセッションもレベルが高かったですね。全体を通して、ソフトウェアを活用した効率改善・自動化を全力でしている、という事例が多くて、とても刺激になりました。最近、自分が担当した業務では、引き継いだシステムをなんとか解析して、手順書を作るくらいで力尽きてしまっていたのですが、もっと自動化していかないとダメだなあ、と。ペパボの事例は、既にあるシステムをガンガン改善していく事例として、見習わなきゃいけない、と思いました。いや、完成度の高いツールだとは思っていたんですが、利用する場面ってもっと限られたツールだと思い込んでいました。一度使ってみたほうがよさそうです。以下、個人的に興味を持った講演中心のメモです。Mackerel開発におけるScalaとGo、そしてPerlMackerelで複数のプログラミング言語を、どのような基準で使い分けているか、という講演。タイトルからして大人気講演だと思うけど一番狭い部屋か......と思って行ってみたら、案の定大混雑でした。(Scala)ゲームほど頻繁にリリースするわけではないので問題ない(それでも毎週リリースはしてる)Javaも良いと思うが、社内で関数型を書きたい人がいたOptionは便利コンパイルは遅くて、だいぶストレスはある。クリティカルなバグは混入してないので、固いものを作れるのではテストが遅い。セットアップが簡単マルチプラットフォーム対応が比較的容易フットプリントが小さく、監視対象のパフォーマンスへの影響小さい事例mackerel-agent(ユーザのホストにインストールする常駐プロセス)mkr(Mackerel操作のためのコマンドラインツール)URL外形監視ワーカー(URL外形監視用のジョブキューシステム。キューにはRedisを使用)blogsync(はてブロ用のクライアント。golang-stats-api-handler開発中に、Perlモジュールの思想を受け継いだモジュールをいくつか書いた型がありつつ、コンパイルが早いので嬉しい。Windowsパッケージングが大変(rpm/deb/msi)Goの使いドコロコマンドラインツールmicroservicesを実現するコンポーネント大きすぎるものにはマッチしない。AppVeyor(msiのコンパイルに使用)Mackerelに関するCPANモジュールMackerelのAPIクライアント、Mackerelのwebhookを受け付けるWebサーバプロジェクトの渋い脇役:だいたいどこでも入っているシェルスクリプトで書くくらいならperlでやりたい自動化スクリプトにツールを同梱できる柔らかいアプリケーションサーバレイヤとしても使える(はてブの顧客向けAPサーバ部分に使おうとしてる)全部Scalaでやるのは大変。本番でも、主キーをシーケンス、ユニークキーをシリアルに変更してみた。短縮update(ステータスの更新)も遅かったindexの再構築がかかるため、遅くなったと思われるステータス管理をやめ、管理テーブルを作成し、update自体を不要にした。3ヶ月後に某サービスでCM打つのでバーンとやってほしいRailsでできたサービス。当時はAPサーバ6台。用途不明のサーバもあるような状態。担当者じゃなかったけど、なんとかしてほしいと頼まれた。yano3(全員フルスタックエンジニア)最初はPuppet化Puppetを使い始めていたが、本番投入されてなかったまず、Puppetを本番投入できるように、サーバマニフェストを全部書き換えた。ppファイル約5500行。SSH)SSHを使わない、という方針にすることで、自動化が進む無駄が起こりうる作業を一旦やめてみることで、イノベーティブな方法が思いつくcloud-initAWS、OpenStackなどを使っている人は、絶対使っているはずドキュメントが非常に少ない。コードを読んだりして対応。