DjangoCongress JP 2022
感想
先日の PyCon JP 2022 に引き続き、同窓会！という感じだった
先日時点で「ひさしぶりー！」したので、今回は再会の感動がちょっと落ち着いた感じ
今回トークに申し込んで発表もしてきました。
発表しようと思った理由は？
一言で言うと、発表者になった方が楽しいからです！なので、1年に1回はカンファレンスなどのイベントでなにか紹介したいと考えてます。
イベントは参加するだけでも得られることがたくさんあるんですが、発表者になるとさらにメリットがあります。発表するための資料まとめ、情報の裏取りなど、それ自体が学びになります。また、聞いてくれた方からの質問やアドバイスなどたくさんのフィードバックをもらえる可能性があります。実際に今回もたくさんのフィードバックをもらえました。
なにより、他の発表者の方が共有してくれた知識を使って仕事をしている身としては、自分も知識を共有することで、恩送り（コミュニティー全体への利益の循環）が大事だと思っています。
発表テーマを選んだ理由
私の発表「OpenTelemetryでWebシステムの処理を追跡しよう」は、複雑化したWebサービスの状態をモニタリングするための技術、"OpenTelemetry"をDjangoで扱う方法の紹介です。OpenTelemetryは2021年にバージョン1.0がリリースされた、パフォーマンスを測定する方法のWeb業界における統一規格であり、オープンソースのリファレンス実装です。まだまだ未成熟なところもありますが、これまでベンダー各社が独自規格で提供してきた仕組みが統一され、相互運用を可能にする規格として期待しています。なにより、オープンソースなので自分でコードを読むことも、修正したりコントリビューションしたりもできます。
自分自身がその規格と使い方を理解して使って行きたい、できれば何らかのコントリビューションをしたい、というモチベーションがあり、さらにそれを多くの人に知ってもらうことで利用が促進されれば、その結果として使う事の理解が得られやすくなり、この技術を採用しやすい環境が整っていくと考えています。なにより、Webシステムの開発や運用はかなり複雑化してきているため、OpenTelemetryの導入によって開発運用に必要な負担を下げられれば、そのための労力をサービス自体の品質向上に向けられると考えています。
発表内容や発表中の様子、感想
発表時にライブデモを行いましたが、一部動作があやしい瞬間があってドキドキしました。無事にデモが成功してよかったです。
発表スライドは、1カ月くらい前から作り始めて、壁打ち代わりにビープラウド社内の技術交換イベント BPStyle で3回に分けて紹介させてもらうなどの練習をしました。3回目の練習をイベント2日前にやらせてもらったんですが、参加した同僚の反応をみて「あ、この流れだとつまらないな」と思って、9割作り直しました。結局当日朝8時くらいにやっと完成しましたが、当日の発表ではみなさんから良い反応、フィードバックをもらえたので頑張った甲斐がありました。
https://www.slideshare.net/shimizukawa/lets-trace-web-system-processes-with-opentelemetry-djangocongress-jp-2022 に資料を掲載しています。スライドの最後に、頂いた質問と回答を追加しました。
参加した理由
スピーカーとして発表することになったのが大きいですが、それ以上に、関心のある技術のイベントが現地開催されるのであればぜひ参加したいと思っていました。2020年のCOVID-19以降イベントで集まる機会がすごく減ってしまいました。イベントで誰かと話をすることが新しい技術を知るきっかけだったり、モチベーションの種になっていくので、この機会を逃さずに参加しました。他の方の発表を聴く優先度はそこまで高くないのですが、現地参加していなければ触れなかった発表や技術に出会えるのも楽しみの1つです。
講演の内容で印象に残ったもの
発表1番目のtell-kさんはトーク開始時間にギリギリ間に合わず、駅から走って会場入りしたときにみなさんから拍手で迎えられていました（オフレコですが、明け方に資料が完成して気が緩んで寝坊したそうです）。発表中もだいぶ息切れしてました https://twitter.com/shimizukawa/status/1591241654841004033
イベント全体を通して印象に残ったこと
休憩時間や昼休みが多めで、人との交流が生まれやすいプログラム構成になっていたと思います。休憩時間には、あちこちで会話がうまれていて、現地イベントはこれが良いんだよなーと、しみじみしました。ビープラウドの同僚同士があつまって雑談するシーンもあって、オフィス閉鎖から1年半ぶりの再会で盛り上がってました。
参加して得られたも
楽しい時間とモチベーションかなあ。学びに行くぞ、という感じはまったくなく、新しい技術に出会って、出会った人と話をして、終わったら懇親会にいって、一日掛けてお祭りに参加した感じでした。IT技術とお祭りが自分にとってすごく近い位置にあることを再認識しました。こういったイベントに全力で参加して、モチベーションをもらって、また次の発表ネタ候補を集めながら次のお祭りに参加しようと思います。
昨年以前との違いでいいなと思ったこと
会場の「日経カンファレンスルーム日経・大手町セミナールーム」はプレス発表などでも使う場所ということもあって、廊下は写真撮影NGだったりしましたが、オープンソースの無料イベントでこういった会場を使わせてもらえるのはとてもありがたかったです。昨年の長野開催では、東京から長野に移動することによる「イベント始まるぞ！」という自分の中でモードが切り替わる感じがありましたが、今年は自宅から30分で着いちゃうこともあって会場についてから徐々に盛り上がってきた感じでした。
その他
全力を出しすぎて、その後数日ちょっと燃え尽きてました。いやー、やりすぎたなー。反省を活かして、また来年も全力で臨みたいと思います！
朝
9:45 会場入り
検温、消毒。
受付は他のイベントも行われる都合で撮影禁止でした。
Djangoのアプリはどういう単位で作るべきか？ 10:20 - 11:05 ROOM 1
by @tell_k
スライド
Djangoアプリを頑張って分けず、1アプリでモノリス実装してしまう場合もある
Sentryは1アプリにmodelsディレクトリを作って目的別に分けている
OCP オープン・クローズドの原則
SOLID 原則の1つ
質疑応答
Q. (今日あとでトークする者です) 一度作ったアプリを分ける必要がでてきたらどうするか？
A. 再構成する機会がいままでなかった。
新しく追加する機能については新しいルールでアプリを作っていく
既存のアプリはできるだけ再構成しない
どうにもガマンできなくなったら、再構成するのがよい
「いま実はその段階なんです」
Q. (お名前不明) シグナルについて。アプリ間で依存があることそのものが悪いことではない？
A. そう思います。依存することはしょうがない。
単方向で依存させることは問題ない > auditlog アプリの例
APIサービス「ケンオール」のアーキテクチャ 11:15 - 12:00 ROOM 2
by @moriyoshit 小泉 守義
スライド
TBD
Python/Djangoを選んだ理由
慣れてたから
機能豊富な DRF を使いたかった
サービスの開発スピードを最優先
質疑応答 (11:40~)
Q. () 質問は複数でも大丈夫ですか？
はい。それに応じてTシャツプレゼント枚数が増えるとかはないですが
Q. () SQLite は検索用？保存用？
郵便番号の正引きはSQLiteが速い
逆引きのような全文検索は tantivy が速い
Q. () SQLite は同時更新に弱いとか、遅いという話も聞くが
検索に使う分にはとても速いです
Q. () SQLite を起動時にS3から取ってくるということだが、ECSタスクを再起動している？
はい。そのとおりです
Q. (ICテック コジマ) Python/Djangoが得意なメンバーだったということだが、Rails全盛期だったりのなかでDjangoを選択した背景をもうすこし聞きたい
サービスローンチが2020年で、メンバーがPython得意だった。
PythonでやるならDjangoだよね、となった
それ以外の背景は、もしかしたらデータサイエンス、機械学習も絡むかも？という淡い期待もちょっと。
Q. (スタッフ) 多くの利用者がいるとおもいますが、同時利用などの利用のされ方をどう見ていますか？
ALBの数値でみていたり
Kinesis Firehose で集めたものを見ていたり
metabase を使ってみていたり
Q. (@takuan_osho)
Q. (@c_bata_) 利用している技術スタックについて: Django ORM は?
SQLAlchemyはDjangoモデルではない SQLite からデータ取得するためのクエリビルダとして使っている
Q. () 郵便番号APIの月間UUなどは？もし言えなかったらそれでも大丈夫です
A. ほにゃほにゃほにゃ...
あっ、わかりました
昼休み
肉食べた
写真
TBD
午後
日経電子版でのDjango活用事例紹介 14:00 - 14:45 ROOM 1
by Yuri Umezaki
スライド
TBD
速度問題
250リクエスト / インスタンス くらいが精一杯
Goに置き換えられる一部APIを置き換えた
パッケージ管理
開発用パッケージの管理がうまくできなかった
dependabotなどの処理が遅くなってきた
いまはこれ
マスクしてしゃべると疲れますね
（会場 
わかる
リードレプリカ環境でDjango Adminにログインしたい
DB書き込みができない
SESSION_ENGINE を signed_session_cookie にし、最終ログイン時間の更新を止めたら出来た質疑応答
Q. (ホリエ): golanのあたりで、キャッシュで捌けないのは、どういうワークロードなのかもう少し詳しく
A. Goに置き換えたのはキャッシュできるところ。
VCL(Fastly)の間違いで効かなかったことがある
ユーザー毎のキャッシュはエッジキャッシュでも対処できない
Push通知直後はアクセスが集中するので、APIリクエストを減らすようにアプリを調整する
レコメンドを減らす、など
Q. () マルチリージョンでのデータベース同期について、ツール、レイテンシ
A. Amazon Auroraを使っているので、レイテンシは小さい
しかしAurora使いすぎると費用が高くなりすぎるので、一部RDSを使っている
目的に合わせて使い分けている
Q. (ニシオ) 開発がDjangoということが採用メリットあるでしょうか？
A. 2015年から使っているが当時はDjangoユーザーはあまりいなかった
近年は機械学習でPythonを使う学生もおおく、そういった人がPython/Djangoを始めやすい
最近の学生、技術者は言語によらず優秀になってきている実感がある
Q. () Djangoを7年使ってきたノウハウが成熟していると感じました。ナレッジのチーム間共有などについて工夫されていることはありますか？
A. 70リポジトリ以上あり、2017年ころから法人向けサービスなどが増えてきている
最初の電子版APIのコードを元にして展開していった
社内Djangoテンプレートを作ったり、技術交流などしている
Djangoで管理する全文検索エンジン 14:55 - 15:40 ROOM 1
by Yuki Takino
スライド
TBD
質疑応答
Q. (BP @tell_k) ESはindexリビルド時にダウンしちゃうんですが、どうしてますか？
A. そのへんはこれから。
同期的にシグナルでやろうかなと思ったけど、同期にすると待たないといけなくなる
保存したらCeleryタスクでインデックス更新、ということを考えたけど、まだ実戦していない
A. django-heystack 最初は使いやすかった。ただ対応してない機能を使いたい場合は困った
(BP@tell_k) 以前 django-heystack を使おうと考えたことがあったけど、まったく更新されてなかったので諦めてました。使えるようになったと知れてよかったです。
ESが破壊的変更をしてくるので、それへの追従が大事なら django-elasticsearch-dsl の方が安全かも
OpenTelemetryでWebシステムの処理を追跡しよう 16:15 - 17:00 ROOM 2
by Takayuki Shimizukawa
スライド
コード
質疑応答
Q. Python 向け opentelemetry-sdk の完成度が低い気がしませんか。asyncで使うとgRPCが詰まる問題があって困っている
A. asyncで試してないので分からないですが、sdkの完成度は低い感じがします。opentelemetry-rubyをRedmine(Rails)に設定してみて、そちらの方が定型コードを書く必要がなかったりして、完成度が高く感じました。
Q. Reactに計装しているコードを見てみたんですが、 TRACEを扱う範囲の指定を BaseOpenTelemetryComponent でラップしているようですが、React hooksを使った場合はどう実装する感じですか？
A. すみません、React初心者なので分からないです。Reactのexampleコードではこの書き方しか見つかりませんでした。もうちょっとSDKのAPIを読めばなにか分かるかもしれません。
Q. OpenTelemetryを使って、エラーが出たときに検知したり、そのときのリクエストデータや変数などが分かるようにできますか？
A. OpenTelemetryは基本的に生データを扱わないようになっていると思うので、生データを見るために、今日のデモではDjango Instrumentorのrequest/response hookを設定して、そこでカスタマイズする方法で実現しました。エラー時のデータを見たいのであれば、Sentryがかなり優秀なので、Sentryを導入した方が良いと思います。
Django 管理コマンド manage.py を深掘り 17:10 - 17:55 ROOM 1
スライド
> #djangocongress manage.py migrate --prune で、migration fileが存在しないのにDBのdjango_migrationsに残っている行をけす。Django 4.1から。へーー>
質疑応答
Q. (RevCommオカダ) 4.1からの機能などはリリースノートを確認した感じでしょうか？
A. はい。リリースノートを確認しました。
（ 同僚からの質問だｗ）
Q. (@aodag) invoke や nox などのカスタムコマンドとの使い分けなどはありますか？
A. DBを見に行くことが多いので、
manage.py を使わざるを得ない感じですA. まだしていないです
Q. (BP @tell_k) 昔
manage.py を読み込むのは私も昔やりましたが、コマンド特有のびっくりした事などありますか？A. パッと出てこないです
(BP @tell_k) 面白いと思った実装をみかけたら、共有
Q. @aki_yok optimizemigration ってどういう意図のものかよく分からなかったんですが..
A. makemigrations で作れないファイルを書いた後に実行するのかなと思います
tokibito もしかしたら、squash migration したあとで実行することを意図しているのかも