Application Re-Architecture Technology
Struts 1.x系からSpring MVCへの移行した際の事例紹介。
事例ベースでこんなところでハマったよー というお話も良かったのですが、
移行までの計画の事例や、自動で移行出来るものの整理、移行時に流用出来るものの整理は、なるほどなーと思う内容でした。
Java EEユーザーから見たSpring
Java EEユーザがSpring Frameworkを使ってみて感じたこと。
Java EEのユーザではないのでJava EEの説明になるほど～と頷いてしまった。。。
とは言ってもSpringについての説明で、ためになるものも色々とあった。
- DI時にコンストラクタインジェクション推奨
- コンストラクタ内でチェック出来たほうが便利
- フィールドインジェクションだとついつい、フィールドを増やしすぎる（たしかに・・・）
- Springの方が画面有りの機能は作りやすい（出発地点が違うというのもありますが）
- REST APIでJava EEに分があると思っていたが、実際には大差ない。（Springが良くなっている）
Let's Visualize Your Spring Cloud Applications!
今後マイクロサービス化を進めていくとなると運用での可視化が必須担ってくると思い、拝聴してきました。
ツールの説明等は割愛するのでスライドで確認してみてください。
今回の話は主に以下の3点
- サービス感の依存性を可視化
- ログファイルを可視化
- サーバやプロセスの状態を可視化
Spring Cloud Sleuth + Zipkin でサービス間の依存関係を可視化
- 改修時などに影響範囲を確認したい。
- エラー時に確認すべき範囲を特定したい。
- 実際に利用されていないサービスがあれば停止したい。
Dev向け。
マイクロサービス化するとなると必須になってくる情報だと思います。
大量のサービスを経由して動作する用になるため、依存関係がはっきりしていないと迂闊に改修出来なくなりそう。
Elasticsearch + Logstash + Kibana + Filebeat でログファイルを可視化
- アプリケーションログの可視化
- システムが安定稼働してるかの把握
- アクセスログの可視化
- 適切にレスポンスを返せているかどうかの把握
- 急激なアクセス増などが起きていないかの把握
Ops向け。（Dev向けも含まれてるかな）
サービスの拡大に伴って、ログが増加、重要なログが埋もれるのでは。。。という危機感があったのでタイムリーな話でした。
Elasticsearchを利用することで、雑にログを取り込んで置いて後から集計軸を変えるなども可能なので、実際の運用に合わせてチューニング出来るのは非常に良いと感じました。
Elasticsearch + Kibana + Metricbeat でサーバやプロセスの状態を可視化
- サーバリソースの状態を把握
- 異常時にリソース情報とログ情報を並べて確認
リソースの確認はどこでもやっているのでしょうが、ログ情報と並べて確認するというのがポイントです。実際にトラブルが起きるとリソースの状態とログを突き合わせていますが、この辺りの作業が楽になりそうな気がします。
また、ログを日常的に見る習慣が付けば今まで気がついていなかったトラブルの予兆（実は問題ありの機能）に気づけるかもしれません。
Microservices Architectureを超大規模プロジェクトでやってみた。
大規模プロジェクトで実際にMicroservices Architectureへの移行した事例を元に色々と説明をしてくださいました。
技術的な内容よりも、チームのあり方や精神的なものを全面に出したお話で、意外と聞けるチャンスの少ない話だったので興味深々でした。
全部まとめると長いので、気になったところだけ抜粋です。
MSAへの移行は難しい、けど出来る！
精神的な難しさを以下のように表現していました。
- 「諦める事」への慣れ
- 「仕様」という言葉の魔法感
- ノーガードになる
- パラダイムシフトを許容できない
- 目に見える範囲で「改善」を積み上げる
逆に技術的な難しさについては、結局は組み合わせなのでなんとかなるという趣旨のことを言っていました。
このあたりは共感出来るところもあって、普段の現場でも当てはまるところあるな。。。と思わずにはいられませんでした。
依存性の分割
実際にシステムを分割していく上で、「意味ある単位」にシステムを分解する。
- 業務機能での何となくの塊（完璧でなくていい）
- 共通機能と業務機能は絶対に別
- ここは理解が得られやすい
共通分は意外と切り出しやすいので、まずは分割してみてるということを言っていました。
ソースを綺麗にするのは置いておいて、まずは優先的に切り出せるものから手を付けるのは良いなと感じました。
※全部まとめてやろうとするとやる気が起きないだろうな。。。と
システム構成はシンプルに
要は、何事もシンプルな構造にする方が良いということで、MSAもApplicationとLibraryに分けて、Application間での通信はWebAPIで統一する。
といった感じで、極力シンプルにすることを推奨していました。
これは同意見で、変に凝りだすと後々、手が入れづらかったり、勘違いが起こるのでシンプルイズベストかなと思います。
ビルドの単位を切り離す
ビルドの単位も機能毎に分ける。
開発担当のやることが増えるかもしれないが、担当が名確になり、責任感が生まれる。
データの分割
理想解はデータはサービス間で共有しない。
ここはある程度の諦めも必要ではないかと話していました。
実際は、自社のサービスを考えてみても、機能ごとにサービス化しても複数のサービスに跨って利用されるデータは多いと思います。
その他、施策等
- リリースはwarからDockerファイルへ
- CIの役割を明確にする（jenkins名人ががんばらない、MS単位のリグレッションテスト、MS間の結合テスト）
- スライドのまとめのところを確認してください。。。
時系列に添って、どのようなアプローチを試し、その改善策を考えてきたのかを説明してくださいました。
技術的なアプローチももちろんですが、個々人の意識が改善されるように啓蒙活動するのが大切と強く言っていました。
まとめ
Springの話を聴きに行ったのですが、MSAの話が色々なところで出ており、
世間的にMSAへの移行が進んでいるのを感じました。
クリアする課題は非常に多いとは思いますが、ある程度の割り切りで
一歩ずつ進むのも重要なのかも？ と思いました。