2022年11月12日開催のDjangoCongress JP 2022に参加しました。
昨年はオンラインとオフラインのハイブリッド開催でしたが、今回はオフラインのみ。 会場は日経カンファレンスルームでした。
日経カンファレンスルームの様子
Djangoのアプリはどういう単位で作るべきか？
スピーカーはtell-kさん。
以下のような状況の開発において、適切にDjangoアプリケーションを分けるにはどうすればよいか、というお話でした。
- 同時に開発する人数2〜10人ぐらい
- 数ヵ月〜数年間、保守をしながら継続的に機能追加・改修がある
事前にアンケートを取ったところ、開発チームにDjangoアプリケーションを分けるための指針がないと答えた人が約9割いたとのこと。
適切な設計のためのヒントとして、UNIXの哲学"Do one thing , and do it well"（ひとつのことをうまくやれ）を参考にしたそうです。
以下のようなお話をされていました。
- 直交性（Orthogonality）（=何かを変えた時、ほかに影響を与えない）があるか考える
- アプリケーションを複数作るのを躊躇しない
- アプリケーションどうしが疎結合になるよう設計する
- 依存（import文）を単方向に限定するのがよい
- 双方向の依存だと循環importの原因になる
- チームで依存関係のフローを意識する
- 以下を利用すると依存関係を単方向にしやすい
- シグナル
- ミドルウェア
- アプリケーションとURL構造を一致させると、URL構造に引っ張られて無駄な依存が増えてしまう。そのリソースを持つアプリケーションで実装すると依存が少なくなる
- オープンクローズドの原則を満たせるようなアプリケーション構成を目指すとよい
Django 4.1 での Asynchronous
スピーカーはJunya Fukudaさん。
Djangoの非同期対応の歴史とこれからの展望についてのお話でした。
まず最初に、Python自体の非同期対応と、Djangoの非同期処理の歴史について時系列で紹介。
非同期処理の効果を調べるため、APIを複数回呼ぶサンプルアプリケーションを同期処理、非同期処理の2パターン用意してパフォーマンスを計測したところ、非同期処理のほうが圧倒的に高速だったそうです。
ただし、O/Rマッパの非同期インタフェースは現状ではsync_to_asyncを使って「非同期っぽく」しているだけで、データベースとの通信を非同期化しているわけでなないとのこと。
Djangoの非同期処理は今のところO/Rマッパに関しては恩恵を受けられないため、外部APIとの通信など、データベース以外のI/Oバウンドな処理が多いアプリケーションでの活躍を期待できそうです。
（余談ですが、私が不採択になったプロポーザルの内容と結構被っている上に、こちらのほうが濃い内容だったので、私が落ちたのは納得でした）
日経電子版でのDjango活用事例紹介
スピーカーはYuri Umezakiさん。
Umezakiさんの職場である日本経済新聞でのDjango活用事例を紹介されていました。
日経電子版のシステムの一部はDjangoを使って構築しているとのこと。
Djangoのよいところとして、以下を挙げていました。
- 管理サイトでデータベースの内容を簡単に確認、変更できる
- あらかじめ社内向けDjangoテンプレートを用意しておくことで、社内で知見の共有がしやすい
- 情報が充実していて研修がしやすい
- データベーススキーマ管理まで一元的にできる
- 特にマイグレーションが行いやすい
Django以外にも、大量のリクエストにも耐えられるシステムを作るためのインフラ構成についてのお話もありました。
バックアップリージョンでリードレプリカのデータベースに書き込めない問題がありましたが、セッションをCookieに保存することで解決したそうです。
Djangoで管理する全文検索エンジン
スピーカーはYuki Takinoさん。
Django + Elasticsearchで全文検索機能を持つアプリケーションを作成するお話でした。
Django本体の機能だけを使って文字列の部分一致検索を実装すると、データ件数が増えていくにつれて性能が著しく劣化するため、Elasticsearchの導入を検討したそうです。
DjangoにElasticsearchを組み込むため、最初に採用を検討したのはdjango-elasticsearch-dslというライブラリ。 直感的に使えるものの、Djangoらしくないコードを書く必要があり、Elasticserachの知識がかなり要求されるため、採用は断念したそうです。
次に見つけたのは、django-haystack。
こちらはDjangoらしいコードが書けて学習コストも低そうということで、採用を決めたそうです。 ただし、django-haystackは更新頻度が緩やかでElasticsearchの最新機能はサポートしていないので、Elasticsearchの機能をフル活用したい人には向かなさそうです。
OpenTelemetryでWebシステムの処理を追跡しよう
スピーカーはTakayuki Shimizukawaさん。
現代のWebアプリケーションは構成要素が多すぎる。 さまざまな要素のログをOpenTelemetryで集約して、処理全体を再構成して把握する、というお話でした。
実際にデモアプリケーション（nginx + React + Django）を操作しながら、各要素のログがOpenTelemetryによって1つの流れとして把握できるところを実演されていました。
似たようなことができる既存サービスではなく、OpenTelemetryを使っている理由として、以下を挙げていました。
- 標準規格なので手を出しやすい
- OSSだからすべてのコードを確認できるし、自分で変更もできる
- OpenTelemetryだけを使わず、併用してもよい
研究から始まったプロダクトをDjango restframeworkを使ってモダンな実装へ変えていく過程の紹介
スピーカーはNakamura Sousukeさん。
スマートフォンを用いた道路の総合管理ツール「RoadManager」に関する改善の課程についてのお話でした。
「RoadManager」は研究から生まれたサービスで、プロトタイプとして作ったものをそのままサービスとして提供したとのこと。そのため、当初想定していた使い方、使われ方を大きく逸脱してしまったそうです。
具体的には、以下の問題が起こっているとのことです。
- 複雑で読み解きにくい実装
- 1つのDjangoアプリケーションにすべてのModel、Viewが集約されている
- 関数ベースビュー、クラスベースビューが混在している
- Django REST frameworkのSerializerを使っていない箇所がある
- Adminに追加で設定された機能がAdminの表示を遅くしている
- Modelの構造上JOINが多いためパフォーマンスに問題がある
改善のために、以下について取り組んだそうです。
- 開発サイクルの確立
- スクラムの導入
- チケット/PRで記録を残す
- テストコードの追加
- CIの導入
- リファクタリング
- SeparateDatabaseAndStateを活用して、データベーススキーマは変更せずにモデル定義だけ別アプリケーションに移動させた
- OneToOneで分離されているが、実際は両者を同時に更新する必要があるモデルどうしは1つに統合
- Adminの検索は
search_fieldsの代わりにget_search_resultsを使用 - SentryでN+1問題を検知して、問題がある箇所に
prefetch_relatedメソッドの呼び出しを追加
クロージング・LT
クロージングでは3名によるLTがありました。
LTの様子
LTはオフラインイベントだと盛り上がりが違いますね！
書籍がもらえるじゃんけん大会もあったのですが、負けたのでもらえませんでした 😢
【番外編】非公式パーティ
公式なパーティはなかったのですが、有志でパーティ（というか飲み会）を開催しました。
非公式パーティの様子1 非公式パーティの様子2
最後に
PyCon JP 2022に参加した際にも感じましたが、やはりオフラインイベントにはオンラインにない独特の雰囲気というか、楽しさがあります。 コロナ禍が長く続くことで、若い人にはオフラインイベントの雰囲気を知らない人もいるという話を聞きますが、エンジニアどうしで集まって盛り上がる文化があることはなくなってほしくないなと思います。
今回は東京が会場でしたが、地方で少人数であってもこういった雰囲気のイベントはできると思います。この記事を読んで少しでも興味が沸いた人は、自分でイベントを立ち上げてみると、きっと楽しいと思いますよ！
ところで、私がコアスタッフとして関わっているPythonのチュートリアルイベント「Python Boot Camp」があります。 地方でイベントを開催して盛り上がりたい人は、まず相談からでもOKなので連絡してください！（とさり気なく宣伝してみる）