エキスパートを招いたナイトセミナーですごく良質なセッションが聞ける勉強会でした。
今回はイベントスタッフとして参加しました。
jjug.doorkeeper.jp
[Java Track]の最後のセッション「Microservices Gone Wrong!」に参加することができたのでレポートしていきます。
「Microservices Gone Wrong!」レポート
私たちはAmazon / Nettlixから何を学ぶことができますか？
- コスト削減や過度の構造化に最適化されていない
- コスト削減の代わりに先取りに重点を置く
- 市場へのスピードに焦点を当てる（最初のムーバーの優位性）
- 狂気の成長を助長するために自然のように組織された
- クラウドは戦略的な利点です！
- ほとんどの通常の企業は、コスト削減とリストラを求めています
- ほとんどの普通の会社はAmazon / Netfixの規模を持っていません
- ほとんどの通常の企業は、コストを節約する方法としてクラウドをまだ見ています
- あなたがふりをするならば。あなたは無料でインフラの問題をすべて解決します
Microservicesを成功裏に採用した企業は...
- ...彼らは金融/ヘルスケア/トレーディング/ショッピングサービスを提供するIT企業であると判断した
- ...クラウド（技術）を戦略的優位性として受け入れる
- ...固体のCl / CDプラクティスを確立し、1日に複数回プロダクション環境にデプロイ
Companies that have successfully adopted Microservices have...
- ...determined that they are an IT company which happen to offer financial/healthcare/trading/ shopping... services
- ...embraced Cloud (technologies) as a strategic advantage
- ...established solid Cl/CD practices, and deploy to production multiple times per day
実際にはどういう意味ですか...
- 組織がソフトウェアアーキテクチャと互換性があることを確認する
- あなたの（マイクロサービス）アーキテクチャがあなたの組織が構造化されている方法を反映していない場合、その方法を気にしないでください！
- それはあなたのチームがクロスファンクショナルでなければならないことを意味します。構築、維持、生産に必要なものはすべてチームの一員でなければなりません
What it actually means...
- Make sure the organization is compatible with the software architecture
- If your (microservices) architecture does not reflect the way your organization is structured, dont even bother going that way!
- It also means that your teams should be cross-functional. Everyone you need to build, maintain and get it into production must be part of the team
マイクロサービスを正しく行うための単一の方法はありません！
There is no single way to do microservices right!
Struggles
- データ戦略
- （非）同期プログラミングモデル
- オーケストレーションとコレオグラフィー
- トラップを再利用する
- テスト戦略
- 失敗に対処する
Struggles
- Data Strategy
- (A)synchroncus programming model
- Orchestration vs Choreography
- Re-use Traps
- Test Strategy
- Dealing with Failure
A truly, asynchronous...
真に非同期で、完全に分散されたイベント駆動型アーキテクチャは、心配気のないものではありません！
A truly, asynchronous, fully distributed, event-driven architecture is not for the faint of hearted!
分離
- バルクヘッドを適用してカスケード接続を避ける
- 転送中には、プロセスを区画に分割し、違反があった場合には封鎖することができます
- ソフトウェアでは、カスケード接続によるシステム全体の不具合を防ぐためにサービスを分離する
Isolation
- Avoid cascading failures by applying bulkheads:
- In shipping: partition the load into sections allowing you to seal them off if there is a breach
- In software: isolate services to prevent cascading failures to cripple the entire system
- 障害ユニット間の結合を減らす
- 非同期通信
- 場所の透明性
- 緩やかな時間的制約
- 偶数性
- 自己封じ込め
Loose-coupling
- Reduce coupling between failure units through
- asynchronous communication
- location transparency
- relaxed temporal constraints
- idempotency
- self-containment
レイテンシ制御
- タイムリーでないレスポンスを検出して処理し、カスケード障害を回避します。
- タイムアウト
- 回路ブレーカ
- ファンアウト＆すばやい返信
- 束縛されたキュー
- シェッドロード
Latency control
- Detect and handle non-timely responses to avoid cascading failures through:
- Timeouts
- CircuitBreaker
- Fan-out & quickest reply
- Bounded queues
- Shed load
- 正しく適用してコードを分解しないようにしてください：
Anti-fragility
- Try to make code less breakable by correctly applying:
- Encapsulation (OOP)
- Open/Closed principle
- Test Driven Development (TOD)
Microservices are NOT...
マイクロサービスは、あらゆる組織のエンタープライズアーキテクチャの論理的な次のステップではありません
Microservices are NOT the logical next step for enterprise architecture in every organization
Microservices are...
- 独立して導入可能なサービスのスイートで、ビジネス機能を中心に編成
- あなたの頭の中に収まるように十分小さいので、それらを捨てることができます
- システムレベルでのモジュール性の促進
- ..継続的な展開で繁栄します。 DevOps、およびインフラストラクチャー
- いくつかの組織でビジネスの機敏性を達成する正当な方法
- 間違った理由のために適用されたとき悪夢が永遠に起こります！
Microservices
- ..are suites of independently deployable services, organized around business capabilities
- ..are small enough so they can fit in your head and you can throw them away
- ..are all about promoting modularity at the system level
- ..are thriving on continuous deployment. DevOps, and infrasructure auicomaticn
- ..are a legitimate way of achieving business agility in some organizations
- ..will cause nightmares forever when applied for the wrong reasons!
所感
Microservices関連は日本でも多くの登壇資料が存在していて、それだけ注目を集めています。
ユースーケースにおいて、日本人も海外の人も同じような内容を共有しているなと感じました。
それだけ、日本と海外でMicroservicesに関する認識齟齬が少ないということなのかもしれませんね。
↓の写真はOracleのサーバラックと明治神宮野球場。
こういう機会がないとサーバラックはなかなか拝めないかも。
以上です！
