先日公開したPyCon JP 2018 1日目のカンファレンスレポートはいかがでしたでしょうか？ 本レポートでは引き続き、2日目の基調講演やカンファレンスなどの様子をご紹介します。
前回の繰り返しになりますが、PyCon JPは、Pythonユーザが集まり、PythonやPythonを使ったソフトウェアについての情報を交換し、Pythonユーザが交流をするためのカンファレンスです。PyCon JP 2018は2018年9月15日に株式会社HDEで行われたスプリントを皮切りに、9月16日のチュートリアルと9月17日～18日のカンファレンスを大田区産業プラザPiOで行いました。
2日目も磯蘭水氏の基調講演を皮切りに、素晴らしいセッションが多数発表されていました。その中からいくつかをピックアップして紹介します。各講演・セッションの紹介の最後に、動画やスライドのリンクも紹介してあるので、当日参加した方もできなかった方も、気になったものをさらにチェックしてみてください。
2日目基調講演「Pythonでやってみた〜広がるプログラミングの愉しみ〜」 ― 磯 蘭水
（二宮健）
2日目の基調講演はAWS Enterprise Support Senior Technical Account Managerの磯蘭水氏による講演でした。
最初に「Pythonを使い始めて今年で20年になる」という、磯氏が実際に送ってきたこれまでの開発人生を振り返り、後半では趣味の開発を例に「技術ドリブンではなく、『何かをやりたい』と思って始めたらこれらの技術を手に入れた」「実際にやってみることで『何がコアな技術なのか』『どこが難しくてどこが簡単なのか』目利きができるようになる」という会場を勇気づける講演をされてい
ました。
磯蘭水氏
それでは、講演の内容をもう少し詳しく紹介していきます。
磯氏は学生時代、分散AIの研究をされており、当初はCommon LispとCで開発していたそうです。そんな中で研究室のメンバーにソースコードを共有するため、「Lispっぽいパワーを持ちつつも、トラディショナルな文法を持つ言語」を探していたところPythonに出会ったといいます。社会人になってからは検索エンジンや、ECサイトの開発、アドテクノロジーの開発などに携わっていたそうです。
次に、ご自身の経験から「プログラミングには2つの主要な動機がある」という話をされていました。1つは目的を達成する手段として「面倒くさいことを簡単にする」という動機を挙げていました。これは、仕事の開発のような場で、手間をかけずに最大の成果を得るため、既存のライブラリも最大限利用して開発するものだそうです。もう1つは「いったいどうなってるんだ？面白そう」という好奇心がベースのもので、ホビーの世界で、自ら体験することが目的にコードを書くものだそうです。
後者の例として、自作のシンセサイザー開発の実装や、そこから学んだ教訓を共有されていました。まずは、PSG音源の仕組みを真似して和音の合成やエンベロープの設定が可能なプログラムを用意し、次に人が読みやすい「楽譜」をプログラムに渡すためMML（Music Macro Language）からMIDIに変換するコンパイラを実装したそうです。そこから学んだ要素として、「まずは単純な構成から始めて複雑にするとよい」「アイディアそのものを再発明するのではなく、モデルを真似して再実装する（磯氏自身は「車輪の再発明」ならぬ「車輪の再実装」とも表現されていました）」などを紹介されていました。
最後に、「プログラミングは工業としての側面とアートとしての側面の両方があり、どちらの動機も大事だが、工業の視点だけが強い人が多い。既にあることを知りつつ『車輪の再実装』をすることでエンジニアとしてのベースの部分を厚くしてくれるのではないか」と締めくくっていました。
Djangoアプリケーションにおけるトイル撲滅戦記
（二宮健）
株式会社アイリッジのサーバーサイドエンジニアである松田康章氏による発表です。
トイルとは、「本番サービスに関する作業で手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例する」もののことであり、SRE（Site Reliability Engineering）の中「Google社が提唱・実践しているシステム管理とサービス運用の方法論」ではこの「トイルの撲滅」が主な目標の1つとして目指されているそうです。この発表では、アイリッジ社内で運用されているDjangoアプリケーションを例に「トイルの撲滅」を目指して活動していた取り組みが紹介されていました。
スタートアップの人手不足で外注に出していたアプリケーションを、今後の拡張を考慮して内製化したところ、同じような依頼を受けて開発できない「トイルにもがき苦しむ時代」が来てしまったといいます。方針として、以下の3つの手法・指針を積極的に使ったそうです。
また、具体的に行った活動として、以下のようなものが挙げられていました。この記事で具体的に触れませんが、もしご興味があれば最後に紹介する資料や映像を見てみてください。
- Docker-Composeを活用して開発環境構築を簡単にした
- Amazon ECSとGitLab CIを活用してデプロイ作業を自動化した
- AWSのCloud Watch Logsを活用して、ログの監視・調査を容易にした
- RDSの負荷が高かったため、Django QuerySetで生成されるクエリを高速化した
- ログを残さずにエラーが握りつぶされていていたため、リファクタリングで改善した
- AWS X-RAYを利用して、本番環境の状況をリアルタイムで把握できるようにした
これらの対応により、「障害対応が減った」「エンジニアリングに割ける時間が増えた」そうです。それに加えて「キャリアアップもできた」という嬉しい効果もあったようです。最後のまとめとして、「『それってトイルじゃね？』の精神」で問い続けること、トイルは無限に湧き続けるので「継続的に改善できる状態を作る」こと、「Managed Service・CI/CDの活用」を行うことを重要な点として挙げられていました。
松田康章氏
最後に会場からの質問もいくつか挙がっていました。たとえば「どのように優先度をつけていたのか」という質問に対しては「サービスの稼働に影響を与えるトイルから優先して撲滅していった」と答え、「CI/CDの自動化でDBのマイグレーションが問題になると思うが、どのように解決しているか？」という質問に対しては、「デプロイ時にマイグレーションが行われるようにしている。そのためダウンタイムは発生してしまうが、あらかじめ説明して問題を回避している」と説明していました。
発表を聞き終わってみると、意外にDjango独自の話は少なく、むしろ他のフレームワークを使っている開発者でも活用できる内容だったと思います。特にAWSを活用しているエンジニアは以下の資料や動画をチェックしてみてはいかがでしょうか？
C拡張と共に乗り切るPython 2→3移行術
（二宮健）
次に紹介するのはGROOVE X株式会社に所属する末田卓巳氏による発表です。この発表では、株式会社GROOVE Xでのロボット開発でPythonを利用している上で、C言語で書かれた拡張モジュールが原因で移行に苦戦し、それをどのように克服してきたかをサンプルコードとともに紹介されていました。
ロボット開発では、クラウドの開発環境と違いスケールアップが難しいため、特に低レイヤーで、実装の楽さよりも高速な動作が必要とされるそうです。そのモジュールに多くのアプリが依存することもあり、GROOVE X社内の場合は、センサやマイコンとやりとりする値を格納する共有メモリにアクセスするモジュールがそれに該当してしまったといいます。この「共有メモリモジュール」では、CのAPIをまず実装し、そこから各言語向けのバインディングを実装という戦略をとってきたそうです。
発表では、さらに簡単なサンプルコードを使って、どのようにPython 2/3を互換化していったかに触れられていました。まずドキュメントを調べ、「（Python 3では）変更がたくさんあったので、Python 2のAPIを無傷で済ませることはできませんでした」と書かれており、拡張モジュールのAPIはPython 2/3間で互換性が無く、必ず改造が必要になることがわかったそうなのですが、「大変だがやるしかない」と腹を括って互換モジュールの作成に臨んだそうです。
末田卓巳氏
実際に修正が必要だった点として、以下の3つが挙げられていました。
- Python2/3で互換性のない文法は__future__, six, python-futuren等で互換性を確保
- モジュールのエントリポイントが全く異なる部分はC言語のプリプロセッサ（#if, #else, #endif）で乗り切る
- Python2のstr使用箇所は、Python3でbytesに直す必要がないかチェック
質問もいくつか挙がっていました。たとえば「2/3対応する時に、C拡張ではなくてctypesを使う選択肢は無かったのか？」という質問に対しては、「私も新しく書くとしたらCFFIやctypesを使うと思う。実際にPythonのガイドにもそう書いている。」と答えていました。
REST APIに疲れたあなたへ贈るGraphQL入門
（花井宏行）
昨今「GraphQL vs REST」という形で紹介され、Rest APIの次のパラダイムとして注目されている GraphQL 。その特徴と用途、GraphQL やそれを簡単に使うための AWS AppSync の使い方をTsukagoshi Keisuke氏にご紹介いただきました。
詳細はレポートの末尾に資料と動画へのリンクを載せているのでそちらをご確認ください。
満席のセッション
セッションはGraphQL自体のおさらいから始まりました。GraphQLとは、APIのためのクエリ言語であり、型システムを使って実行するためのサーバー側のランタイムの総称で、「取得（クエリ）」、「変更（ミューテーション）」、「購読（サブスクリプション）」ができるデータ言語です。
REST APIで課題となる、API仕様の管理や、オーバーフェッチ（余計なデータが取得される）、アンダーフェッチ（1回の問い合わせで十分なデータが揃わず、複数回問い合わせる必要がある）と言われる、1回のオペレーションに複数のAPIのレスポンスが必要になってしまう問題を解決できます。
特徴としては以下の3点が挙げられました。
「型指定されたスキーマ」により、APIの定義をするだけでドキュメントの自動生成やクエリの実行環境がGraphQLサーバーによって提供されます。
「クライアントからのレスポンス形式の指定」ができるので、オーバーフェッチ、アンダーフェッチを回避できます。クライアントは必要なデータを指定することができるので、REST APIよりもクリーンなインターフェースを提供できます。
「購読を利用したリアルタイム処理」を実現できます。チャットアプリのようなリアルタイム性が必要な場合、購読するエンドポイントを指定することで、ポーリングせず簡単にデータをやり取りできます。
Tsukagoshi Keisuke氏が好きなサービスでもあるという、簡単にGraphQLを使い始めることができる「AWS AppSync」について解説とデモがありました。GraphQLサーバーを0から構築することも、用途に合わせて雛形を使って簡単に使い始めることもできるそうです。またGithubでクライアントアプリも提供されているので、クライアントとの動作確認も簡単にできます。クエリの実行環境も提供されており、コードの補完も効くのおで、ストレスなく開発を進めることができるとのことでした。
データ保存先にはDynamoDB、Erasticsearch、AWS Lambdaが選択でき、AWS Lambdaを指定すれば、業務要件に合わせて柔軟にカスタマイズも可能とのことです。
AWS IAMまたはOpenID Connectに準拠した認証機能も提供していおり、認証が必要ない場合にも対応可能だそうです。
いかがでしたでしょうか。GraphQL使ったことがない、難しそうと思っている方にとっては、AWS AppSyncで動かしてみるのがよさそうですね。
ここでは紹介しきれなかった内容がたくさんありますので、以下からぜひご確認ください。
Pythonによる異常検知入門
（花井宏行）
統計的手法から、機械学習やDeep Learningを用いた様々な異常検知アルゴリズムの概要と、Pythonでの利用方法、実際のアプリケーションに組み込む場合の注意点などをご紹介いただきました。
詳細はレポートの末尾に動画へのリンクを載せているのでそちらをご確認ください。
大山匠氏
異常を検知する前提として、「異常」である状態を定義する必要があります。外れ値やベースラインの変化などは、外的要因（隣の機械の振動、担当者の変更による動かす癖の変化、機械の仕様など）による場合もあります。データだけ見ていても、本当に異常なのか判断できない場合があるというのが、難しいところだそうです。
異常検知のアルゴリズムについての紹介がありました。異常は頻繁に起こるものではないので、今回は「教師なし学習」で異常を検知していきます。「教師なし学習」で正常な状態を学習させることで、新たに来たデータの外れ具合から異常であることを検知するという手法を用いるそうです。以下の手法のメリット、デメリットを、Pythonでの実装方法ともに紹介いただきました。
- 外れ値検知：ホテリング法、近傍法、LOF（Local Outlier Factor）、One-Class SVM
- 変化点検知：複数予測モデルのあてはめ（予測モデルからの誤差を計算）、累積和法、Change Finder（外れ値検知を多層的に利用）
- 異常部位検知：近傍法（ウィンドウ処理によって外れ値検知の問題として解く）
- ニューラルネットワークを使った異常検知：Autoencoder
最後に、実際の現場で活用するにあたっての注意点をご紹介いただきました。以下3点がポイントになるそうです。
- 「データの状態」による値の傾向の変化に注意する。電源Offやアイドリング状態が異常として検知されないようにしないといけない。状態の定義は現場の人にヒアリングしながら決める必要があるとのことです。
- 季節性、トレンドなどを除外する、検知アルゴリズムに合わせて分布を変換する（例：Box-Cox変換）など「データのクレンジング」が必要。
- 異常と判定したが、実際はどうだったのかという「判定結果へのフィードバック」を受けて、モデルに反映する仕組みが必要。
いかがでしたでしょうか。工場機械での異常検知のお話でしたが、Webシステム等でも応用できる考え方だと思います。
ここでは紹介しきれなかった詳細は、以下からぜひご確認ください。
2日目ライトニングトーク
（陶山嶺）
1日目と同様に、2日目のクロージングでもライトニングトークがありました。ここではその中から2つのライトニングトークを紹介します。
「diff最小化原理で導くZen of Python」 ― 多田吉克
「diff最小化原理で導くZen of Python」というタイトルで発表してくれたのは、株式会社いい生活の多田 吉克さんです。
Python歴が2年目と若い多田さんですが「2年目なりにPythonを書くときにどうしたらいいか考えてきました」とのことです。「修正コスト = diffの量」と捉え「将来のdiffが最小化されたコードがいいコードではないか？」という仮説を持ったそうです。そのためにできることとして具体的に下記のTipsを挙げていました。
- 複数モジュールのimport文やリスト、辞書などで行末にカンマを書く
- 早期リターン
- （アクセス制御などでは）デコレータを使う
みなさんもコードを書く際の指針の1つとしてdiffを意識してみるといいかもしれませんね。
若手と謙遜しながらも堂々とした立ち居振る舞い
「システム開発素人が深層学習を用いた画像認識で麻雀点数計算するLINEbotを作ったハナシ」― 栗原理央
麻雀、Pythonが好きな栗原理央さんは深層学習を使っている株式会社ブレインパッドのデータサイエンティストです。ご自身が作った麻雀点数計算チャットボットについてライトニングトークをしてくれました。
もともとのスキルからか麻雀点数計算部分は比較的簡単に作ることができたようですが、Flaskとherokuを使ってLINEbotにするところで下記のような点で苦労したようです。
- アプリ立ち上げに60秒かかるとdynoコンテナが再起動される
- 100MB以上のファイルを置けない（深層学習モデルはこれより大きい）
- LINEにReplyできるのはユーザーアクションから30秒以内に1度だけ（モデルのロード/ビルド、推論はもっとかかる）
- メモリが512MBを超えると処理が遅くなる
いずれもHeroku、LINE Messaging APIのフリープランゆえの制約のようです。この制約を越えるために行った工夫は、ぜひ動画でご覧いただければと思います。
トークも上手く、みんな集中して聞いていました
2日目ライトニングトーク一覧
今回ご紹介しきれなかったものも含め、2日目のライトニングトークの一覧はこちらです。
- 暗号通貨技術・ブロックチェーン技術を活用するCrypto-Fintech Lab. : Narisa Takita
- 安全なサンドボックス構築の裏側 ~投資アルゴリズム構築環境QuantX Factoryの事例~ : 康裕三
- diff 最小化原理で導く Zen of Python : 多田吉克
- Python × Investment ~投資信託をPythonで分析して、その結果を公開するサービス作った話~ : Takahiro Kato
- システム開発素人が深層学習を用いた画像認識で麻雀点数計算するLINEbotを作ったハナシ : 栗原理央
- 【poke2vec】ポケモンの役割ベクトルの学習とその分析・可視化 : 喜多智也
- asyncio + aiohttp で作るウェブサービス : Pine Mizune
- PyCon JP 傾向と対策 : ryo kato
また、Pythonの公式アカウントにライトニングトークの動画がアップロードされています。
クロージング
ライトニングトークのあとは、PyCon JP 2018全体のクロージングでした。4日間に渡るPyCon JP 2018全体の参加者数は1156人と、PyCon JPとして初めて1000人を超す規模のイベントとなりました。
また今年のクロージングでは、サプライズとして来年のPyCon JPの日程も発表されました。PyCon JP 2019のカンファレンスデーは、2019年9月16日〜17日に今年と同じく大田区産業プラザPiOで開催されます。来年もぜひ参加してみてください！
