レストラン事業部エンジニアの id:ninjinkun です。

一休レストランでは10年以上動いているシステムをPython 3で書かれた新システム（以下restaurant2）に順次移行する作業を進めています。現在ではPC用のレストランページや主要な API を含め、いくつかのページがrestaurant2で提供されるようになっている状態です。本記事ではこの移行の経緯と、restaurant2システムの詳細、Pythonを選んだ理由、現在の進捗状況をお伝えします。

経緯

一休レストランはサービスローンチ時よりClassic ASP（言語はVBScript）でシステムが構築されてきました（こちらに驚かれる方も多いと思いますが、歴史的経緯という言葉で強引にまとめて話を先に進めます）。このシステムは現在も一休レストランを支えているのですが、長年の改修による複雑性の増加、言語の古さ、言語機能の貧弱さなどにより、事業成長の足かせになっているという事実がありました。

そこで昨年よりrestaurant2プロジェクトが立ち上がり、昨年末にAMPページを切り替えたのを皮切りに、移行が進んでいます。

restaurant2の概要

restaurant2の概要は以下の通りです。

Python 3.7 ･･･ typing, enum, data_classes, async/await (asyncio) など Python 3 の新機能を積極利用
フレームワークは Flask
DDD の Layered Architecture / Clean Architecture を参考にした薄い階層アーキテクチャ
Python 3 + mypy による type-hinting を使った型定義
flake8 + autopep8 によるコード規約 & 自動フォーマット
nosetests w/ factory_boy でのユニットテスト + Circle CI
API Blueprint による RESTful API の管理 / dredd によるドキュメントの自動テスト
フロントエンドは BFF + nuxt + vue.js による Universal JavaScript + コンポーネント指向設計
実行環境は Docker + AWS Elastic Beanstalk (開発環境も Docker コンテナとして提供される)

構成図 f:id:ninjinkun:20180810165928p:plain

Pythonの選定理由

なぜPythonを選択したのかという質問をよくいただくので、こちらで選定理由を説明します。

一休レストランではこれまでデザイナーがマークアップも行うスタイルで開発が行われてきました。また、一部開発が得意なデザイナーはサーバーサイドロジックにまで踏み込み実装を行っていました。デザイナーがエンジニアと一緒になって開発を行うフローは、コミュニケーションロスを大幅に減らしてくれます。これを維持し、デザイナーが引き続き開発に参加しやすいように、開発環境のセットアップ、実装、プレビューまでを簡単に行える環境が求められました。既存システムのClassic ASP環境ではVBScriptをHTMLに埋め込み可能な動的なテンプレートエンジンとして利用していたので*1、同じようにテンプレートエンジンが使える動的言語がターゲットになりました。

この要件に当てはまり、かつ広く使われている言語としてはPerl, Ruby, PHP, Python, JS (node.js)あたりがターゲットになると思いますが、Pythonを選んだ理由としては以下の通りです。

言語仕様がシンプルで学習コストが低い
文法の自由度が低く、メンバー間の書き方の差異が減らせる
- flake8 や autopep8 によりコーディングをスタイルを自動的に統一することも可能
機械学習/AIのデファクトになっているため利用者が拡大しており、今後も言語の進化とエコシステムの高活性が見込める
動的言語でありながら型定義による事前検査が可能

他にも社内にPython経験者が複数人居たり、選定の当時機械学習の勉強会が社内で流行っていた影響でPython熱が高まっていた…などの背景もあります。

マイクロフレームワークの選定理由

また、一休レストランではPythonで書かれたマイクロフレームワークであるFlaskを選択しました。この背景としては、ビッグリライトは行わず、既存のシステムと並行運用しながら段階的に移行して行くという意志決定があり、これにより以下の要求が発生したためです。

DBは既存システムと共用し、スキーマも既存のまま運用する
- しかし既存DBスキーマのテーブル名、カラム名がユビキタス言語的な命名になっていなかった
- 複数テーブルをjoinしないとEntityを表現できない場合があった
- このためrestaurant2ではDataMapperパターンを使い、DBのテーブル構造から独立したオブジェクトを作成、オブジェクト名とカラム名をユビキタス言語に変換している
  - テーブル構造とオブジェクト構造が一致してしまうActiveRecordパターンのORMはこの方針には適さない
  - ORMを自分たちで選べる薄いWAFが望ましかった
既存システムを開発しているメンバーも徐々にrestaurant2での開発に移行する
- キャッチアップのし易さを考えると、マジカルな部分が多い厚いWAFよりは単純なWAFの方が好ましい