https://www.slideshare.net/yuichi1004/golangtokyo-6-in-japanese?ref=https://golangtokyo.connpass.com/event/57168/presentation/

golang.tokyo #6 (in Japanese)

    1. 初めて で大規模 を作り得 た教訓 golang.tokyo #6
  2. 2. ■ この発表では golang で大規模な Microservices 構成のシステム -- AndApp -- を作った時に得た教訓をつらつらと語っていきます ⁃ 成功談というよりむしろ失敗談の話と、そこから得た教訓の話をしていき ます ⁃ 初めて golang 開発にチャレンジする人たちの参考になれば ■ 初めて Golang を使い、手探りで作り上げていった部署の話を聞いて「あるあ る」も「ないない」もお楽しみいただければと思います
  3. 4. 教訓 フレームワークに拘らない ■ 新規プラットフォームの立ち上げにあたりテクノロジースタックを刷新 ⁃ を基本構成に ⁃ メンバーの開発経験は主に オンプレミス ■ のベストプラクティスを調査 ⁃ まずフレームワークを調査し始める ⁃ 他の言語におけるフレームワークの成功体験 ⁃ チーム開発でもコードに統一感がでるし ⁃ 言語に熟練していない人でも「それなり」に書けるし ⁃ ↑ 部署として に初挑戦するだけにこれが重要だった
  4. 5. で始めた 開発 ■ 当時特に話題性のあったフレームワーク ■ 良かった点 ⁃ シンプルで扱いやすかった ⁃ とのインテグレーションもサンプルにあった ⁃ 問題 • から を派生させ回避 • の一貫性をキープ ■ 困ったところ ⁃ ワイルドカードパスを共有したルーティング問題 • 例えば以下のようなエントリーでコンフリクトが発生する • 例 ⁃ ⁃ • が内部で利用する の制限 gin.Context (App Engine) context.Context派生
  5. 6. 一部で を導入し始める ■ に続いて話題性のあったフレームワーク ■ 良かった点 ⁃ ワイルドカードパスを共有したルーティングが可能 ⁃ 特に アプリ系のコンポーネント開発が捗る ■ 困った点 ⁃ 設計がガリガリ書き換わる ⁃ のリリースノートにて • • コンテキストの派生が不可能に… ⁃ 一時、作者が別の フレームワークの開発に勤しむ • の開発やめるの…？ ■ その他困ったこと ⁃ と の両対応 結果 は 対応を諦め のまま使う。新規のコンポーネントではなるべく を使わない流れに
  6. 7. そもそも でフレームワークに拘ることはない ■ 洗練された パッケージがある ⁃ で事足りるのであればそれでもよい ⁃ 実際いくつかのコンポーネントは で作っている ⁃ など足りない部分は都度ライブラリで補完していけばよい ■ は言語仕様がシンプルかつ がある ⁃ フレームワークに乗らなくてもコーディングスタイルは似てくる ■ ウェブアプリケーションフレームワークに乗っかるのであれば運命を共にする覚 悟で ■ で が パッケージに取り込まれたことで またひと波ありそう フレームワークに拘らない、振り回されない！
  7. 8. 教訓 を尊重する ■ 独自エラー型の使い方でハマった話 ■ 独自 型の使い方でハマった話 ■ は として使おう
  8. 9. 独自のエラー型を定義 ■ 独自のエラー型を定義して利用することに ■ 一般的な 関数の戻り値は インタフェース ■ しかし我々は独自のエラー型に寄せることにした ⁃ なぜなら インタフェースからのキャストが面倒だから ⁃ すべての関数の戻り値を寄せてしまえばいいと思っていた
  9. 10. 思わぬ盲点 ■ 以下のコードはうまく動かない。なぜか
  10. 11. には型があるの罠 ■ の型問題 ■ インタフェースと独自エラー型を混在した時に発生 ⁃ すべてを独自エラー型に寄せきれないケースが存在する • 例 などのサードパーティ関数 ■ 素直に他の関数にならって インタフェースに統一すれば良かった ■ キャストがめんどくさい問題は便利関数でどうにでもなる ⁃ 例 独自のエラー型を作っても良いが標準の インタフェースを尊重すべし
  11. 12. 独自のコンテキスト型を定義 ■ 独自のコンテキスト型においても似たような失敗 ⁃ リクエストスコープの値を簡単に取れるよう を定義 ⁃ アプリケーションで引き回すのを ではなく に寄せ た ■ きちんとコンテキストを派生させていれば問題なさそうに思えるが… ■ 例えば以下の様なコードを書く時に困る gin.Context (App Engine) context.Context 派生 MyContext 派生 context.Context 型になってしまうため、 *MyContext 型の関数に渡せなくなってしまう
  12. 13. は として扱おう ■ の定義されたものは積極的に で扱うべし ⁃ 標準ライブラリや他のライブラリとの連携がシンプルになる ⁃ の活用によってテストが楽になるという副次的な効果もある
  13. 14. 教訓 は遅い ■ 皆さん バリデーションどうしていますか？ ⁃ 弊社では を利用 ■ での として以下が候補に上がった ⁃ • で行くと一番メジャーなバリデータ • 動的に を読み込みながらバリデーションしていく ⁃ • 国産 • のバリデーションコードを生成
  14. 15. ■ 以下の理由により を選択 ⁃ スキーマを複数分割したかった ⁃ スキーマをローカルファイルから読み込みたかった ■ この要件を容易に満たしてくれたのが 複数のスキーマを読み込むため を選択
  15. 16. パフォーマンステストで問題発覚 ■ 予想以上にアプリケーションの動作が遅いことが発覚 ■ 調査の結果バリデーションの有無でパフォーマンスに顕著な差が出ることがわ かった ⁃ バリデータあり • ⁃ バリデータなし • ■ を使って のテストスイートを実行した結果を解析 ⁃ の 時間が 動的にスキーマを解析する部分にくわ れていることが発覚