「要求の変化とマイクロサービスアーキテクチャ」に参加しました

5/17(火) 「要求の変化とマイクロサービスアーキテクチャ」に参加してきました。

DoorKeeper
https://redajp.doorkeeper.jp/events/44052

場所は新宿の日本総合システム株式会社さんです。
参加者は40人くらいでしょうか。

最近、弊社でもマイクロサービスアーキテクチャがキーワードによく上がります。
個人的にも↓の本を読みつつ、MSA読書会にも参加しているところなのです。

マイクロサービスアーキテクチャ

posted with amazlet at 16.05.29

Sam Newman
オライリージャパン
売り上げランキング: 6,391

Amazon.co.jpで詳細を見る

そんんわけで、この日の講演タイトル＆講演者が鈴木さんということで参加してきました。
以下、復習用に当日のメモを書き起こす。

---

講演「要求の変化とマイクロサービスアーキテクチャ」

要求の変化とマイクロサービスアーキテクチャ from yusuke suzuki

SoRからSoEへ　（P.6）

• SoR：　情報を記録する
• SoE：　ユーザー同士の関係を作り出す

サービス運営モデル　（P.7）

• ユーザの「価値」は複数ある。
• ITサービスの後ろには機能（コード）がある。
• その後ろに構造やプロセスがある。
• 一番右の「価値」から、コーディングする、「プロセス」を決める、まで距離がある。
• いろんな関係者がいろんな関わり方をしている。

「作る」から「運営する」へ　（P.9）

• 要求は価値から生まれる。
• 要求を変えて価値を出す。要求も変化し続ける。

要求は変化する　（P.10）

• 変化との戦いに勝つにはこーしたらいいんじゃないか、というフォーマットをとして、マイクロサービスアーキテクチャが最近注目されている

プロジェクトマネジメントの基本　（p.12）

• プロマネの基本、やることは４つしかない

1. 計画する
2. 実行する
3. 計測する
4. 調整する

ウォーターフォールの失敗　（p.13）

• そもそも見積もりが正しくできてないから計画も正しくない。要員通りにできない。
• ズレの調整が、プロマネの腕の見せ所。

アジャイルの考え方　（p.14）

• アジャイルの誤解：計画を適当にせよ
• リソースを固定して、期限も固定して、スコープしか調整できないようにするのがポイント。
• →　計画が正しく立てられるように短期にする。
• 計測：動くか動かないかで１００か０しかない。
• プロジェクトマネージャがしそうな調整ごとをプロセスに織り込んでるのがアジャイル。
• 計画はどうせうまく行かないので調整を重視しているのがアジャイル。
• 長期の計画を正しく立てられるのなら、ｗｆのほうが早く確実に安く上がる。
• アジャイルはいろんなことを犠牲にした上で、みんなで考えながら一歩一歩進む手法。
• 技術でなくプロセスに柔軟を持ち込んだのがアジャイルの重要な考え方。

クラウド　（P.18）

• 2005～2015年はクラウドやDevOpsという言葉が中心となる時代。
• クラウド：所有でなく利用
• 資産から従量課金へ
• コンピューティングリソースにおける規模の経済
• 電力と一緒。人が発電所を持つのでなく、電力を使わせてもらってる。

ソフトウェア化するハードウェア　（p.19）

• SDx （Software Defined ..）　・・・　ソフトウェア定義されるハードウェア.
• これが大きな変更点だった。
• 非機能要件がコーディングできる
• 性能を上げたいなら、サーバを足すというコマンドを実行すればいい。
• コードを変えれば非機能要件が変わる。

Platform as as Service　（p.21）

• PaaSに特に注目すべき。
• OSSのフレームワークを利用するのに似てる。

カナリアリソース　（P.28）

• 鉱山で鳥かごのカナリアが死んだら毒ガスが出ていると判断する。カナリア＝部分的な犠牲。
• 部分的な犠牲（カナリア）を許容することで、無停止で昼間に切り替えられる。
• やってみればいいじゃん、という考え。いいか悪いかは別として。
• 金融とか病院とかはできないので注意。

必要な技術群

• ルータとかもカナリアの挙動をするような新しい製品を使う。
• 各技術群の一番右に書いているのはNetflixが公開しているOSSである。

ダークカナリアリリース　（P.36）

• システム間連携が多いのでステージング環境でテストするのがすごい大変。
• 連携先のモックなんて用意してられない。
• 開発者にしか見えないリリースを、本番環境でやる。
• 本番環境のデータを使ってテストする。

Chaos Monkey　（P.37）

• ちゃんとハードウェアがソフト化されて自動化されているかを確認する。
• ダウンさせても影響なくいけるか確認する。
• カオスキングコング　・・・　リージョンまるごと落とす。
• Monky関連のいろんなツールがある。SSLチェックとか。

マイクロサービスアーキテクチャ　（P.38）

• サービス＝それだけで単体で稼働する仕組み
• APIで連携し、互いは疎結合

MSAの２つの側面　（p.41）

• MSAの9個の特徴は技術的な話と組織的な話に分けられる。
• 技術面：　分散配置と統合
• 組織面：　持続性と分権

MSAの組織面：持続性と分権　（p.42）

• ドメイン＝業務、という言葉が近い
• サービスそれぞれは好きな技術で作って良い。自主性を認める。
• 標準化なんて意味がない。
• 技術は多様化しているので、ドメインに特化した技術がある。
• 尖った仕組みを作れるように。エンジニアがやる気が出る技術使えばいいじゃん。
• ドメイン個別のライフサイクル。自分のタイミングでリリースしていい。
• 犠牲的アーキテクチャ。どうせ変わるんだからあとで作ればいい。

変化するために分割する　（P.43）

• 変更で大変なのは事前調査とテスト。
• サービスに分割されていれば、変更の影響はサービス内部にとどまる。
• データベースも共有しない。

変化とサービス分割　（P.45）

• サービスをうまく分割するのが重要。業務別にサービスを割っていきましょう。
• サービス分割どうすればいいか、というのは正解がない。業務を知ってるあなたが考えることです。
• 全体視点で誰がやるの？は日本の課題。ユーザ企業側に優秀なアーキテクトがいない。
• 日本はSIerにエンジニアがいて、ユーザ企業側のエンジニアは少ない。
• ドメインに従ってサービスを分割するのが大事。

MSAは目的ではない　（P.51）

• MSAに「する」、ではなく、「なる」
• あなたドメイン知ってるんですか？ドメインを理解してないとMSA導入を先導できない。
• ドメインを知らない技術屋が、MSAやりたいんです、は怖い。
• MSAは技術論と組織論のバランスがうまく取れている。
• 建築業界では、工法と構造はセット。itは別々。MSAで両方がセットで語られるようになってきた。

---

感想

マイクロサービスにみならず、アジャイルとウォーターフォールの比較などを交えていろんな視点からサービス開発を俯瞰していました。
とても勉強になります。

講演者の鈴木さん、関係者の皆様ありがとーございました。