先日 builderscon tokyo 2018 にスポンサーとして協賛＋1名のエンジニアが登壇します でご案内しましたbuilderscon tokyo 2018に参加していくつかのセッションを拝聴しました。
名前は以前から知っていましたが今回初参加となるbuilderscon。
とてもユーモアの効いたオープニングから始まり、2日間に渡り多くのセッションが実施され、最近の技術のトレンドや他の企業様の取り組みなどを知れる良い機会となりました。
あっという間の2日間でたくさんの学びがありましたが、そんな中でもとくに印象に残ったセッションについて私個人の感想とともに紹介しようと思います。
Envoy externals and ideas
初日(前夜祭を除く)の最後を飾ったセッションです。
初日はサービスメッシュに関連する技術系のセッションが目立っており、どれも満席になって入場規制がされてしまうほどの盛況ぶりでした。
昨今当たり前のようにコンテナ技術が語られるようになり、マイクロサービスアーキテクチャが推奨される流れの中、そんなサービスとネットワークの隙間を埋めるために発展(まだまだ途上?)しているサービスメッシュ技術。
私はサービスメッシュ技術を扱ったことがなく、それこそ上記のような概念を知っている程度の知識でしたがいくつかサービスメッシュ技術のセッションに参加してきました。
初日にはEnvoyの作者のMattさんの内部構造の深い話に始まり、Cookpadさんのサービスメッシュの取り組み、Istio開発者による説明と簡単なデモ、その他参加できなかったものを含めるともっと多くのサービスメッシュをテーマにしたものがありました。
そんな中でも私が最後に参加したサービスメッシュ関連のセッションが本セッションでした。
マイクロサービス化が推し進められた結果うまれる運用の課題に、サービスメッシュを使ってどういう切り口で解決していくかというポイントを「サービスの境界線」というキーワードを使って分かりやすく説明されています。
正直サービスメッシュのディープな話になればなるほどついて行くことが出来なくなっていましたが、このセッションに関してはどちらかと言うとサービスメッシュの門をこれから叩く人に向けたような内容となっていたのですんなりと聴くことが出来ました。
最後に聴いたサービスメッシュ関連のセッションでしたが、他のセッションに参加する前に聴けてたら良かったなというのがセッションを聴いた直後の率直な感想でした。
このセッションを聴いてからであれば他のセッションの理解度ももう少し上げられたのかなと。
スピーカーの@seikoudoku2000さんはマイクロサービスを推し進めた後の課題にどう対応するかを検討している際に、その問題を解決するためのプロダクトを自分で作るという真っ向勝負に出たEnvoyを知り衝撃を受けたそうですが、その気持ちはスゴく共感できました。私も何か課題があった時につい解決の近道となるライブラリやプロダクトを探してしまい、自分でモノを作るという発想になかなか至らないので、そういうソフトウェアエンジニアとしての本来の姿を目の当たりにするといつも反省してしまいます。
サービスメッシュ入門としても最適な本セッションでしたが、そんなソフトウェアエンジニアとしての初心も振り返らされたセッションとなりました。
つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側
取り扱っている情報の秘匿性の高さからマルチテナントなサービスを構築するという選択をしたSmartHRさんを待ち受けていた苦難と、それをどう乗り越えたかというとても生々しくもあり、けどとても身になるお話でした。
笑いどころたくさんで終始笑いの絶えない楽しいセッションで、他人事のように終始笑いながら聴いていられましたが、これが自分の身に降りかかっていたらと考えるだけで胃が痛くなりそうです。
他人事とは言いましたが、弊社にもデータベースにまつわるレガシー問題は存在するので、そういう意味ではとても親近感を感じました。
マルチテナントゆえのスキーマ変更、データのマイグレーションの難しさを実際の事例をもとに説明し、それにどう対処して解決したかというリアルなお話。
実際の事例を曝け出し、検討したことや対処したことを時系列的に説明する流れだったので、自分でも追体験してるような感覚を味わうことができました。
話を聴いているだけだと「うんうん、そういう設計ならそういう問題が起こっても不思議ではないよね」と簡単に何が起きたかの裏側を理解できるんですが、それを設計や実装前から予想できるかというと…. そんな案外簡単に予測できそうで、実際にやってみないとなかなか顕在化しない実運用上の問題というのは、書籍やWebを見てもなかなか情報は得られずに経験に頼る部分が多いので、それを問題発生から解決までの道程を短時間で聴けたのはとても良い経験でした。
セッションの終わりに「移行前後のデータの整合性のチェックはどうしたか?」と質問したところ、「ユニットテストで大部分を担保し、サービスの要となる部分についてはその他に目視だったり、画面を実際に触って」という回答を頂きました。
データベースの移行の難しさやその苦労とともに、ユニットテストなど自動化テストの重要性も再認識させられました。
RDB THE Right Way ~壮大なるRDBリファクタリング物語~
データベースの基本に立ち返って、
- 「情報」と「データ」の違い
- 「論理設計」と「物理設計」の違い
- 「アプリケーション」と「データベース」のライフサイクルの違い
をもとにデータベース設計はどうあるべきかをとても丁寧に説明したセッションでした。
データベース設計の進め方に始まり、アンケートフォームの具体例を出してそれをどう設計すると良いのかなど、非常にわかりやすい内容です。
個人的には「データは成長する」という言葉にハッとさせられました。
「サービス開始当初と数年経った時ではデータ量もデータの扱われ方も変化する。だからデータベースは正しく設計しておこう。」というメッセージそのものが、本セッションのテーマでもあります。
すごく基本的で当たり前なことだけれども、それを実践できているとはなかなか胸を張って言えないような部分の重要性を再確認させられました。
また、サービスのほぼ全てに関係し、かつサービスの根幹となるデータベースを疎かにしてしまうことの危険性は認識しているつもりでしたが、本セッションを通してただ危険性を認識しているだけで、それと戦うための道具がまだまだ足りてないことにも気付かされました。
セッションのまとめに「データベースはいくつかの良い本を読めば十分な知識がつく」とある通り、データベース道の王道を歩めるようにいくつか書籍を読もうと思います。
まずは「SQLアンチパターン」を初心に戻って読み直します。
余談ですが、「データベース実践入門」の第1章は大学の講義のような内容で難しいという小話がありました。
過去に読んだときに第1章の難解さに本を投げ出しそうになった経験があるので大笑いしてしまいました。
最後に
初日のセッションではサービスメッシュの話を聴く機会が多く、昨今ではコンテナという言葉が当たり前のように使われているのと同じで、数年後はサービスメッシュ(もしくは同じものを指す別の言葉)が当たり前に使われているんだろうなという近い将来を予想させてくれる内容で、2日目はどちらかというと今目の前にある課題にどう取り組むかというテーマに寄ったセッションを聴く機会が多い印象でした。
2日間を通して過去と未来を見つめ直す良い機会を頂けました。
次回も何らかの形でbuildersconに参加しようと思います。
スピーカーのみなさん、運営のみなさんありがとうございました!!
※ ここに書いたものの他にもたくさんのセッションがあり、スライドも公開されていますので興味のある方はこちらからどうぞ!!
