契約による設計とテスト駆動開発で大きいタスクを楽にする
こんにちは。
id:shallow1729です。先日一ヶ月ぐらいの工数のかかる大きめのタスクを担当しました。そのタスクは機能に関連するテーブルやエラーになる条件が多く、初めはどこから手をつけたらいいか分からない状態でした。今回紹介する契約による設計とテスト駆動開発は自分がうまくとっかかりを見つけて手を進める上ですごく役に立った開発手法です。うまく実装を進められない時とかに思い出してもらえたらと思います。
大きいタスクの難しさ
これはエンジニアとしての経験則ですが、規模の大きい機能の開発はたとえそこにアルゴリズム的な困難さを伴わなくても難しいものになるように思います。
もちろん全体のアーキテクチャを考えるには設計手法の理解が必要ですし、関連するツールが増えるとそれらの理解が必要だったりするので技術的な課題に直面しやすいというのも事実だと思いますが、実際に開発をしている中でそういう技術的な課題感が特に無いのに手が動かなくなる場面がいくつかありました。初めは原因がよく分からなかったのですが自己分析してみて以下のような問題があるように感じました。
- 考慮する事の多さに対する疲弊
- 動作確認がなかなかできなくて不安になる
1つめの問題はタスクが大きくなるとそれだけ関連するものが増えるために起きる問題に思われます。ユーザーのデータの状態や入力フォームによって動作が変わる機能の場合、それらの状態や入力の数だけ条件分岐が発生することになります。僕が先日関わった仕事は6個のテーブルに更新が走る処理で、入力フォームやそれらのテーブルの状態によってはユーザーに適切なエラーメッセージを伝える必要がありました。このような実装では例えアルゴリズム的にはシンプルでも考える事が多いので神経を使って実装する必要があります。
2つめの問題はタスクが大きくなると動作確認ができるまでの期間が長いために起きる問題に思われます。普段僕は手元環境を立ち上げて実際に動作確認をしながら実装を進めているのですが、このようなやり方はある程度すでに存在するシステムの拡張をする時にできる方法で、大きな機能開発の場合はコードを書き始めてから実際に手元環境で動作確認できるようになるまでに数日かかってしまう事もあるので使えないケースがあります。こうなると数日間動作確認をせずにコードを書く事になるので感覚的には数日間仕事が進んでないような気持ちがして気分が沈みますし、実際に動かしてみて初めてうまくいってない事が分かって大きくやり直す可能性も見えて不安になります。
ここで書いた課題はどちらかというと心理的な課題に思うのですが、今回僕はこれらの精神的な負担を下げるために契約による設計を用いたモジュール設計手法とテスト駆動開発を実践してみました。今回の実践の流れとしては最初に契約による設計を使って全体について擬似コードを書いて、そのあとモジュールごとに擬似コードをベースに自動テストを実装しながらプロダクトのコードを書くという流れで行いました。こうなった経緯としては初めは擬似コードがあれば実装が進むかなと思ったら思ったより手が動かなかったのでテスト駆動も取り入れたという感じです。実際は擬似コードを書かずに事前条件や事後条件の洗い出しだけしてさっさとテストを書いていく方がいいかもしれないとも思いました。なので、まだまだ工夫中ですが、参考になれば幸いです。
契約による設計について
契約による設計(Design By Contract)というのはBertrand Meyerが考案した開発手法で、コードの品質、特にモジュールの信頼性を高める事で再利用性や利便性を高める事ができ、かつオブジェクト指向で用いる抽象化と非常に相性の良い開発手法です。契約による設計は名前の通りモジュールの呼び出し元と呼び出し先の間で契約を結ぶようなイメージで説明できます。まず、モジュールが呼び出された時、呼び出されたモジュールはその呼び出しに対して適切に処理を行えるかの確認を行います。このバリデーションは事前条件(precondition)と呼ばれます。契約による設計では事前条件を満たさない入力は受け付けない一方で、事前条件を通過した場合に呼び出し先は予定されている処理を実行し、必ず期待されている条件を満たす実行結果を返すように実装します。この期待されている条件というのは事後条件(postcondition)と呼ばれます。たとえ呼び出し先のモジュールで例外が発生しなくても事後条件を満たさない出力である場合はその出力を返さずに何らかの処理をする必要があります。また、もう一つ不変条件(class invaliant)というのがあって、これは例えば木構造のクラスでノードAの子ノードの親ノードはノードAでないといけない、というような常に成り立つ必要のある条件に関する制約です。これは例えば複数のデータ操作を伴う処理が中途半端な段階で失敗した時にデータ不整合を防ぐチェックと考えるといいかなと思います。
また、今回の本筋ではありませんが契約による設計は特に抽象化を伴う場合にはLiskovの置換原則を成立させるためのいくつかの条件を表現する事ができます。Liskovの置換原則というのは筋の良い抽象化を行うための数学的な表現で、よくSOLID原則の一つとして紹介されると思います。 例えば抽象化を行った場合のモジュールの事前条件と事後条件の規則を説明すると、抽象化を行う場合、子モジュールは親モジュール以上の値域の入力を受け取れるように設計する必要がありますし、親モジュール以下の値域で値を返さなければ置換不可能な設計になってしまいます。この契約による設計を用いた指針は元々の数学的な表現よりも実装に近くて扱いやすいと思いますし、単に置換可能な設計と言われてるよりも実装のイメージが付きやすくてよいなというのが個人的な感想です。
契約による設計を用いた擬似コード
例えばサインアップのフォームの入力を受け取って確認メールを飛ばすメソッドだとこんな感じかなと思います。
method_name
input: // 入力
user_account: user_account // 変数名と変数の型
email_address: string
password: string
data1: bool
db: db
output: // 戻り値
error_code
pre_condition: // 事前条件
// メールアドレスの形式が使用可能なものか
email_address_is_valid_format(email) == true
error_handle: return 'ERROR_CODE1'
// パスワードの形式が使用可能なものか
password_is_valid_format(password) == true
error_handle: return 'ERROR_CODE2'
// メールアドレスがすでに使われているか？
user_account.exists(email_address => email_address) == false
error_handle: return 'ERROR_CODE3'
post_condition: // 事後条件
// 一時的な登録データの作成は行われているか
temporary_data.exists == true
error_handle: exit
// 確認メールは送信されたか
email.sent == true
error_handle:
count = 0
while (count<5){
retry
count++
}
exit
code: // メインのロジック
// 一時データを登録して確認メールを送信する
token = create_temporary_data(user_account, email_address, password, data1, db)
email = create_confirm_email(token)
send_email(email_address, email)
擬似コードなので文法についてはご了承ください。ポイントはpre_conditionとpost_conditionでこのメソッドの事前条件と事後条件がどのようなものかと、それらのバリデーションに引っかかった場合にどうハンドリングするかを書いています。エラーを返したりプログラムを終了するだけではなく例えばメール送信や画像アップロードなど外部APIを叩く場合はリトライを試すという処理もここに書きます。
契約による設計の枠組みで考えて設計をしてみると分かるのですが、想定内の入力以外を初めに排除する事で入力の多様性について悩む問題が減るのでかなり見通しがよくなります。また、エラーハンドリングや失敗時の処理というあまり楽しくないけど設計能力が問われる仕組みについてもメインのロジックと分離して考える事ができるので筋道が立ちやすくなり、考慮漏れを事前に防げそうだな感じました。この擬似コードはメインのロジックがシンプルなので気になりませんが、複雑な実装の場合はメインのロジックを書きながらエラーハンドリングも書いていくと思考のノイズになりがちな気がするので、そういう例外をメインのロジックから分離して正常系の複雑な部分に集中できて良かったなと思いました。このように契約による設計を用いる事でメインのロジックとそれ以外の処理を分離して考える事ができるので「考慮する事の多さに対する疲弊」を抑える事ができました。ただ、多くの言語で事前条件や事後条件のバリデーションはサポートされていないので、実装時に工夫する必要があります。事前条件についてはunless文を最初にまとめて書けば良いかなと思いますが、事後条件についてはあまりうまく分離ができず、処理を進める中で適宜バリデーションと例外処理を書くしかないなと思いました。とはいえ事後条件については自明なケースも多いと思うので実際はバリデーションしないとかもあるかなと思います。
テスト駆動開発の心理的効用
テスト駆動開発といっても正直僕がやったのはとりあえずテストを先に書いてから実装するというだけの事なので、あまりテクニックの紹介はできません。ですが、それでも先ほど説明した実装時の心理的障壁を解消するには十分な効果があると感じたので紹介します。
まずテストが通る事で仕事が進んでいる事がわかるという安心感があります。しかも契約による設計で例外ケースやエッジケースがはっきりしているのでテストケースはあまり悩む必要がなく、実装もとりあえずバリデーションの実装だけ先に書こうとなるのであっというまに5個ぐらいのテストケースを通るところまで実装できて気分が良いです。また、デグレーションのリスクにかなり強くなるので書いてて気になったら安心してリファクタを行う事ができるのも良かったです。
テスト駆動開発をやる時に心がけるといいなと思ったのは人に見せるテストとはある程度分けて考えるという事です。多くのチームではプルリク作成時にプロダクトのコードと合わせてユニットテストも書く規約にしていると思うのですが、テスト駆動開発を始める時はそういう最終的に納品するコードとは分けて考えた方が良いと思います。例えばあるモジュールに対するテストはだいたいどのテストケースでも同じような初期化が必要だと思います。こういう時に初期化部分を共通化しておこうとか綺麗な設計にしようとかそういう事を初めから意識するとなかなか手が動かなくなる気がします。初めはコピペしながらテストケースをどんどん用意するぐらいのゆるい気持ちで進めて、適宜綺麗にしていくぐらいでいいかなと思います。
終わりに
今回は大きな開発に伴う心理的な負担を和らげる方法という文脈で契約による設計やテスト駆動開発といった開発手法を紹介しました。一方でこれらの手法が筋の良い設計につながるという話題は特にしなかったので興味のある方はいろいろ参考文献を見てみたりしてください。正直開発手法は人間的な側面を無視できないのでこれがベストと言い切れるような指標もなくて議論が難しいなと思うのですが、こういう開発手法を個人レベルで始めるのは自由だと思うので自分なりにいろいろ学んで試してみると開発が楽しくなっていいんじゃないかなと思います。
参考文献
契約による設計については以下の本が参考になるかもです。
https://www.amazon.co.jp/dp/4798111112
自動テストやテスト駆動開発については自分も勉強中ですがこの辺を読み進めています。
異なるシステム間での大量データの同期について
2022/03/19 追記
続編みたいなやつ書きました。 shallow1729.hatenablog.com
はじめに
メリークリスマス!!
はてなのエンジニアのid:shallow1729です。この記事ははてなエンジニア Advent Calendar 2019の25日目の記事です。昨日は
id:hitode909さんの以下の記事でした!
blog.sushi.money
今回はタイトルにある「異なるシステム間での大量データの同期」について、仕事でいくつか関わったので悩んだ事をログに残そうと思います。一緒に難しいねって笑ってくれたら嬉しいです。
「異なるシステム間での大量データの同期」って何のこと？
これは自分がつけた名前なのですが、例としてはシステムを完全にリニューアルするとかでDBのスキーマを再設計したシステムにデータを移すような場合や、あるシステム上の大量のデータをスプレッドシートのようなものに同期させてデータ分析をするようなケースを想定しています。前者のようなシステム移行は一度きりの同期でよくて、後者の場合はどの程度リアルタイム性が必要かによりますが定期的に同期が必要です。
- 同期元のデータを正しく変換する事
- 同期を短時間で済ませる事
- データの整合性を保つ事
前者については、データを正しく変換するには同期元と同期先のデータの両方を理解する必要があるという点で難しいです。一般に一つのシステムのテーブル構成を理解するのはすごく大変ですし、利便性を考えてあまり直感的で無いスキーマ設計をする事もあると思うので、そういうコンテキストも含めてある程度理解しないとうまく変換が出来ないです。また、テーブルのデータを丸ごと同期するような場合はうまく実装しないと数日では済まないようなものになってしまったりします。最後に、そのような大量のデータを同期しつつ、全体として整合性を保つのは非常に困難です。（困難な理由はあとで説明します。）こういう感じでとても難しいのですが、難しいなりに考えたことをまとめていきます。
12/25追記: こういったタスクにはETLという名前があるそうです。そちらで検索するといろいろ詳しい知見が得られそうです!
同期の仕組みの設計
とはいえAPIの設計はコミュニケーションも開発工数も非常に多くかかるものだと思うので、直接DBを見に行くという選択も十分あると思います。状況に応じて考える、で良いと思います。
データの同期方法
データの不整合が発生する仕組みと解決策
APIを介するにしても同期元のDBを直接見に行くにしても、大量のデータを整合性を保って取得することは非常に困難です。例えばある日の22時00分に、前日の22時00分から先に更新された全てのレコードを取得する場合を考えます。この場合前日の22時00分から当日の22時00分までのデータが取得されるのが期待できます。ですが、実際にはリクエストを順番にさばくためにあるテーブルのデータを取得し始めるのが22時05分からだとすると、あるデータは22時00分のもの、別のものは22時05分のものになります。これをある程度解決する方法としては検索範囲を前日の22時00分から当日の22時00分までとして取得することです。(つまり、リクエストの範囲について後ろも指定する。)この場合でも例えば22時05分にあるデータを取得し始めた場合、もし22時00分から22時05分の間に更新が行われた場合には22時00分のデータは消えてしまうことになります。
差分同期と一括同期
データ同期のさせ方としては、同期させるタイミングで都度全てのデータを一気に同期する一括同期と、事前に大半のデータを同期させておいて、都度差分だけを同期する方法があります。差分同期のメリットとしては前回の同期からの差分だけを同期させれば良いので短時間で処理が完了する事です。ですが差分同期は特にデータの削除が行われる場合実装が難しいので、使えるタイミングは限られると思います。
差分同期
差分同期(データは作成しかされない場合)
データが更新、削除しない場合差分同期は非常に有効な手段になると思います。 例えば毎日22時のデータを同期する場合は前日の22時に作成されたデータからその日の22時までに作成されたデータを同期すれば良いです。 また、s3やcloud storageのオブジェクトを他のバケットにコピーするような場合は、作成日時のような情報で範囲指定はできないですが、単純にバケットのデータのキーのリストを同期先のデータのキーのリストと比較して差分をインポートするという実装でも、都度全て同期するよりはずっと短時間で完了します。（当たり前といえば当たり前ですが）
差分同期(データの更新も行われる場合)
更新があった場合は先ほどのデータ不整合の仕組みで説明したような事が起きてしまいます。差分同期の場合の先ほど紹介しなかった他の解決策としては、同期元のシステムから更新リクエストを都度もらうという手もあるように思います。あとは、システム移行のように最後に一度同期が取れておけば良いという場合や、多少データ不整合があっても良いという場合には先ほど説明したような比較的起こりにくいデータ不整合は許容するという手もあると思います。
差分同期(データの削除が行われる場合)
差分同期の難しい点はデータの削除が行われた場合にそれを同期するのが困難な点です。前日に22時以降に更新されたデータを同期する、という条件で同期する場合に前日の22時以前に作成されて同期済みのデータが削除されたとすると、このデータの削除を同期する事ができません。なので、仕組みとしては削除履歴のようなものを同期元に用意するか、削除リクエストを同期元からもらう必要があると思います。あとは毎回全てのデータについてユニークキーを比較して消えてるものを見つけて削除する、という事もできると思います。
一括同期
一括同期は前回同期したデータを全て消して再度全て同期するような実装です。あるいは、システム移行の場合は一度に全てを移行するような実装です。 一括同期であっても同期中に同期元のDBの書き込みがあったりするとデータの不整合は生じてしまうのですが、特に削除される事のあるデータの場合差分同期より実装が楽なので、データがむちゃくちゃ多すぎてどうしようもない時でなければ一括同期は良い選択だと思います。
その他
パフォーマンスチューニング
今回話しているようなケースの場合、データのINSERTが大量にあるので積極的にバルクインサートを使ってN+1を解決するのが重要かなと思います。SELECTの時のN+1は身近な気がしますけど、INSERTでもN+1はかなり強烈で、実際これを解決するだけで10倍程度速度改善できた事もあります。他にはUUIDを払い出す場合もSELECT文が都度発行されるのでN+1にならないように一括で取得すると結構効いたりします。
ページング
APIにしてもDBから直接データを取るにしても、あまり大量のデータを取得しようとするとネットワークのタイムアウトなどがありうるので考慮しておく必要があります。SQLであってもAPIであってもオフセット法やシーク法などの実装があると思います。
エラーログと再実行の処理
システム移行の場合はデータの同期に数時間から数日かかる可能性もあります。そのような時に想定外の事が起きてエラーで止まった場合に備える事が必要です。備えとして必要なことは
などです。 パフォーマンスの点では一つのトランザクションが大きい方がN+1の問題を解決できて良いですが、あまり大きすぎて一つの実行に時間がかかりすぎると途中で失敗した時につらくなるので適切な粒度を考える必要があるかなと思います。
あとがき
以上、異なるシステム間での大量データの同期について、自分なりに考えたことをまとめました。拙い文章ですが最後まで読んでくださってありがとうございます。 2020年もよろしくお願いいたします！
読書中: 低レベルプログラミング (Igor Zhirkov)
始めに注意ですが、これはレビューのつもりでは書いてなくて、今ざっくりとこんな事に興味があるとか最近考えている事について本をテーマに喋ってるだけです。まだレビューが書けるほど読めてないですが、満足するぐらい読んだら何か書くかもしれません。
プロセスの管理とかそういうOSのやってくれる事と計算モデルとかそういうプログラミング言語に関する事については雰囲気が掴めてきたものの肝心のそのつなぎ目がよく分からなくて本を探していた。僕は学生時代物理学とか化学の理論的な研究をやってた人間で、コンピュータの事を真面目に勉強し始めたのは社会人になってITのエンジニアという職に就いてからだ。もう社会人になって一年半も過ぎるのでこの言い訳を外してしまいたいけど、なかなか自分に自信を持てるほどコンピュータに詳しくなったとは言い難い。結局抽象的な事をどんなに学んでも実際に作ったものはノイマン型のアーキテクチャに色々肉付けされた何かの上で動く事になる。なんとなくそういう現実を見ずに理論ばかり眺める事に後ろめたさを感じていたように思う。
この本はアセンブリ言語とC言語とその間について説明してある本で、まだ全体を軽く眺めた程度だが比較的理論的な説明が好きな人に受ける本な気がする。アセンブリ言語を説明するところではCPUなどの実行環境についての説明とその背景についての説明がいろいろされ、コンピュータが今のように非常に難しいものになってしまった歴史について納得しながら読み進める事ができた。正直前提知識が結構多い本に思われて、おそらく情報系の学部で学ぶいろいろな知識はあるのが前提な気がする。とはいえググりながら読み進めたらなんとかなりそうではある。僕のような学生時代に情報系の教育を受けていなかった人間としてはこういう障害はむしろ嬉しいもので、その業界で生きてる人たちにとっての常識の感覚を身につけたり、初歩的な本では載っていない学問的広がりについて知る事ができる。大学教育の良いところは研究の最前線にいる人から直接話が聴けるところで、何気ない雑談の中でその学問の世界が見えてきて、そうやって知識を彩のあるものにしてくれる点にあるように思う。正直この本がいつか振り返った時に良い本だと思えるかは分からないが、なんとなくいつか振り返る事ができるぐらいには深く理解をするきっかけとなるように思っている。昨日頑張って読み進めた結果今朝は脳が死んでしまっていたのでこれからはほどほどに読み進めていきたい。
