コードを書いたら負けなのか？

北海道LT大会で話した資料です

Transcript

1. コードを書いたら負け なのか？ 2023/4/15 北海道LT大会 いとうまさとし Twitter : masatoshiitoh
2. コードを書いたら負け なのか？ • コードを書かなきゃバグは増えない、というのは理解しつつも、 このポリシーもそれはそれでツライよねという話をします • ちなみに最後まで進んでもオチはないです • この発表では、「コードを書いたら負け」は、既存の枯れた OSSフレームワークや外部サービスをうまく使って、できる限 り核心になるロジックだけに集中したいですよね、という意図 で使っています
3. 今日のもくもく • Vert.xのEventBusのコーデックをいろいろ試してました
4. 自己紹介（一瞬） • いとうまさとし（Twitter: masatoshiitoh） • 株式会社セガ札幌スタジオ • セガサミーグループ歴10か月 • 今回のLTはセガサミーグループの技術スタックや開発・運営中 のタイトルとは全く関係ありません（為念 • 過去作品 • Speed.rbbtoday.com（IRI-CT、現イード在籍当時に開発） • 最近のGist • Camel から Camel Vert.x component 経由でVert.xクラスタのイベントバスを読み書きする • とにかくApache Camelを動かしてみるための最初の手順
5. 何か作るときに必要な機能は多様 • 「コードを書いたら負け」で立ち向かうとしたら、さまざまな OSSフレームワークやOSSライブラリ、SaaSの連携をするこ とになるわけですが、、、 • フロント（アプリ、Web） • APIサーバー • キャッシュ • 認証・認可 • バッチ処理（集計とか） • 管理画面 • CSVとかによる一括設定 • 外部システム連携
6. 連携対象の「お作法」が全部違う • みんなちがって、みんないい
7. 連携対象の「お作法」が全部違う • みんなちがって、みんないい ・・んなわけない
8. 連携対象の「お作法」が全部違う • みんなちがって、みんないい ・・んなわけない それぞれに合った使い方をしないと、そもそも作れない、まとも に動かせない
9. 連携対象の「お作法」が全部違う • SaaSはまだいい。WebAPI等、使い方が固まっている
10. 連携対象の「お作法」が全部違う • SaaSはまだいい。WebAPI等、使い方が固まっている • ライブラリはドキュメントが不足していたり、更新も数年止 まってたりしがちだけど、だいたいの場合、動くなら問題なし。 そのバージョンで固定してしまえばいい…あとで困りがちです が。
11. 連携対象の「お作法」が全部違う • SaaSはまだいい。WebAPI等、使い方が固まっている • ライブラリはドキュメントが不足していたり、更新も数年止 まってたりしがちだけど、だいたいの場合、動くなら問題なし。 そのバージョンで固定してしまえばいい…あとで困りがちです が。 • フレームワーク類は、それぞれに合った使い方、書き方、動か し方を把握するだけでもハードルが高い
12. 連携対象の「お作法」が全部違う • フレームワーク！
13. SpringBoot • Javaでウェブサービス作るときの定番（たぶん） • アノテーションの嵐だが、コーディングしやすさ感は高い • Initializrサイトで始めやすい • 書籍やウェブサイト上の情報が多くて人気 • バッチ処理機能とかも持っている。何でも作れそう感に満ちて る
14. Jakarta EE (Eclipse foundation) • (このへんからオーバーキル） • 何か大きめのアプリケーション作るときの定番（たぶん） • 昔のJava EE • 今から飛び込むには壁が高い（昔から飛び込みにくい • コンテナって何？アプリケーションサーバーって何？ • DBアクセスするWebアプリを書いて動かしてみよう、ってい うだけでも大仕事になりがち。設定をアプリケーションサー バー側に寄せられるので、コードには処理だけ書けばいい、と いう構成になっているが、初学者には準備多すぎてツラい
15. Eclipse Vert.x • Java用の非同期フレームワーク • Quarkusの非同期処理のベースとしても採用されるなど、実績強い • Starterサイトがあって始めやすい • 何でもコールバック • Vert.xでは自分のコードでIO待ち等のブロッキング処理を書くのは基本厳禁 • ブロッキング処理が必要なのでWorker Threadを自前で作って管理する、というの は負けパターン • Vert.xが提供する非同期クライアントライブラリ(DB/Redis/HTTP)の使いこなしが 正道 • DB、Redis、設定読み込み、、、何をするにもコールバック • 随所でコールバックヘルが爆誕
16. Apache Camel • Enterprise Service Busのオープンソース実装 • よさそうなんだけど情報少ない、調査つらい • とはいえさすがに標準で含まれているコンポーネントは「動作する」 • 動かない時は「使い方」「呼び方」が間違ってる • 接続や変換はDSLスタイルで定義。よい。 • from～～to～～でデータの流れを表現 • 多様なコンポーネント • 各コンポーネントについての情報量の差が大きい • たとえば、ActiveMQは割と充実しているっぽい • 一方、Vert.xコンポーネントはかなり少ない
17. Apache Kafka • ストリーム基盤 • PubSubとかメッセージルーティングとかが強い • 永続化とかもしてくれる • 開発用にちょっと触るだけなら、Bitnamiのdocker compose 定義を使うのが一番簡単。PC1台で動くし。 • プロダクション運用に載せるのがすごとい大変そうに見える • 小規模で動かしてる分には、それほどでもないのかな、、、？ • ChatworkのCQRS+ESの基盤に使われていると聞いて、「す ごそうだなー 便利そうだなー」レベルの理解でしかありませ ん、ちゃんと使ったことないです
18. つなぐ方法も悩ましい • Kafka、MQ、ESB、HULFT、gRPC、Web API • ファイル渡し、DB渡し、Redis渡し • FTP、S3 • あとからどうとでもなる部分（毎週月曜朝にDBからCSV作っ て実績レポートにするとか）を考慮外にしても、割と大変 • 考慮外にした部分が牙をむいてくることも、たまに、、、
19. 他にもいろいろ悩ましい • XMLとJSONとCSVと、、、 • 同期、非同期 • 1 to 1、PubSub • at lease once / at most once / exactly once • タイマー起動、イベント起動 • 定期的なデータ削除 • サーキットブレーカー、メンテナンスモード • メンテ時、ウェブサイトは止めていいけどAPIサーバーは止めちゃダメ、み たいな案件もありました。どっちも同じサーバーで動いてるんだけど、的な • インフラレベルで考慮してないとどうにもならない
20. 可用性上げる方法が悩ましい • スケールアウトさせる場合も、結局どこかがパフォーマンス上 の律速段階になりがち（多くの場合はDBかネットワーク帯域 ですよね？） • ネットワークって信用しきれないですよね • リカバリは？ • そのバッチ、リランして問題起きない？ • 障害検知は？ • ログは？
21. どうせ負けるなら、いっそモノリスに… • ツールの調査をする時間で作れるなら、作った方がいい？ • データの流れはコードの流れで表現できるよね • 同一プロセス内ならデータの受け渡し速度がネットワーク経由の比 じゃない • フォーマット変換は「外との界面」でだけ発生させれば、、、 • リカバリはそれでも問題になりがち • そもそもモノリスだと影響範囲確認が大変になりがち • 金融系でおこなわれているという「コピペしてきて不具合箇所を修正 （その修正されたコードはその処理フローでしか使われないことを担 保）」という方法が魅力的に見えてくる • 修正新規とか、コピー新規とか言われるらしいですね
22. 「する」と「なる」は違う（余談） • 何も考えずに外注すると、モノリス（というか泥団子）になり がちじゃないですか？ • 外注業者がどこかの案件で作ったと思われるコードをベースに 作られた「何か」が納品されてきて、運用や改修で苦しんだり してませんか？ • これは「モノリスにする」を選んだことにはならないよ？ • 余談なのでオチはありませんよ？
23. みなさん今ってどう設計してますか？ • 今だとAmazon AWSのアイコンを並べてフローを検討して、 それを念頭にいい感じに開発すれば、だいたい動く？？ • API GatewayとLambda、SQS、DynamoDB、S3あたりで 組めれば、だいたい問題ない気もするんですよね • クラウド系のサービスは「単体でドキュメントどおりに動く」 ことがほぼ確実で、環境構築がポチポチで済むのはありがたい • （これもオチはありません）
24. We are hiring • ここまでの話は所属会社とは関係ありません • 過去に携わったシステムの経験をもとに「どうやったらよかっ たのか」「ほんとに書いたら負けなのか？」を振り返る感じ • いろいろ書きましたが自分自身は「書いたら負け」派です。自 分がこれから書くプログラムが、長年生き延びてるコードより 安定してるとか思えませんので • あと、セガ札幌スタジオはWe are Hiringしてます
25. We are hiring(大事なことなので再掲) •We are Hiring •セガ札幌スタジオ 中途採用、で検索！