QCon Tokyo 2016 <Engineer Track>
参加した上での雑なメモ書きです。聴き逃している箇所も多分にあるので、資料のリンクがあるものは資料を見たほうがいいです（笑
http://www.qcontokyo.com/index_et.html
Twitter #qcontokyo
2016年10月24日(月)9:45～18:20
ベルサール新宿グランド コンファレンスセンター
東京都新宿区西新宿8-17-1
住友不動産新宿グランドタワー 5F ベルサール新宿グランドコンファレンスセンター
開会のご挨拶
荻原 紀男 株式会社豆蔵ホールディングス 代表取締役社長
10年近く続いているイベント
テーマ説明
羽生田 栄一 株式会社豆蔵 取締役 CTO QConプログラム委員長
ITが変革するビジネス・組織・社会
QConは、世界的なカンファレンスとして、海外各国でも実施されている
基調講演1 エンジニアリングの物語り(ストーリーテリング) ～人に語るに値するカルチャー
Engineering Storytelling - Culture Worth Talking About
Pete Soderling 氏
Hakka Labs
@PeteSoder
ニューヨークとサンフランシスコでスタートアップを実施
最高のエンジニアリングチームを組成するためにはどうすればいいか
- Why culture and stories matter
- Cultual "features" using examples from U.S. tech companies
- Tips ....
Why culture and stories matter
かんばんやAgile、Trello／Githubといったツールを使ってコラボレーションしている
- ツール自体が Culture ではない
他のチームじゃなくて、ウチのチームに来る、というのは文化で決まる
決してコードだけのコンフリクトではない
- クリエイティブな問題をどう解決するか？が文化によって変わる
ほかと比べてこっちが重要だ、というのが文化
アメリカではチームの多様性が問題になってきている
- チームにもっと女性を入れる、とか
- データサイエンティストにどうやってコーディングを覚えさせるか
- 広範にすべての人々にコーディングを教えることが課題
- Code.org
- TechCrunch #hackath_n
OSSの裏は企業のサポート
- 公にサポートしていることの重要性
エンジニアをリモートで仕事させるための仕組み
- Slack
- オンラインで応答ができるかぎり、在宅勤務で構わない
卓球テーブルがある仕事環境
- エンジニアがリラックスできる環境
- ペットを連れて出社してもいい、とか
上記のそれぞれが文化というわけではない
特定の規範的なレシピを伝えるつもりはない、正解はない
- トレード・オフを伴うもの
ストーリーを語って、文化を説明する
- ストーリーは文化的なアイデアを伝えるもの
Sapiensという書籍
- 人間が協力することによって「企業」という物語に繋がった
- 「国」や「地域」もストーリー
エンジニアには心理的なものは受け入れ難い、と言われている
...
- 我々が存在する意味
- 知識の共有
- モチベーションを高める
なにを気をつけるべき？
- Become a better leader
- Inspire others to join your team
- Keep your team together
なぜエンジニアリング文化が重要か
twilio
- 電話ベースのコミュニケーションアプリ
- エンジニアを繋ぐ方法が欲しかった
- twilio がエンジニアを繋いでいる
- エンジニアは皆 twilio が好きだった→購入した
- twilio は、エンジニア間を流れていた物語を実現した
- twilio は愛されています、あなたの開発者に聞いてみてください
- エンジニアは twilio で働きたい、とも思った
Cultual features & examples from U.S. tech companies
特徴として重要なのは、自主性・『自律性』
あまり管理されないで仕事をしたい、と思っている
- Googleはエンジニアによって設立され、エンジニアのための企業である
- Googleは実験をすることを好む
- 20%ルール
- 毎週1日は好きなことができる
- 多くのイノベーティブなプロダクトは20%ルールから生まれた
- インスピレーションは、自由な発想から生まれる
- 他の企業も少なからず20%ルールに近いものを導入しようとしている
- ハッカソンでいつもと違うチームで何か意味が無いかもしれないことに取り組む
- エンジニアに自律性を生ませる
- 20%ルール
- トレード・オフはある
- Googleは非常に大きな企業
- Alphabetという企業に作り直した
- 自分自身の文化を一旦、破壊することも重要
- 文化を変えるために必要
- Googleは非常に大きな企業
『インパクトを与える』
- facebookは映画化された、内容は非常に正確
『Ownership』
Etsy
- 手作りのものだけを売るマーケットプレイス
- ユーザの文化と結びついている
- 自分で構築し、自分で運用してください
- 自分が書いたコードがうまく動かなかったとき、自分で責任を持ってなんとかしないといけない
- Ownershipを重視する
- 他の人・QAに頼らない
- コードをリリースする前にチェックリストを自分で確認する
- 自分のコードを書いて所有することにプライドを持つ文化
『学習（Learning）』
エンジニアは誰も学習に意欲的
- Pivotal Labs
- 学習を全く新しい次元に引き上げた企業
- XP を採用
- ペアプログラミング
- 2人のエンジニアが常に一緒に仕事をする
- お互いのコードを見て意見を出し合う
- Pivotalはこのモデルにコミットしている
- ビジネスにとっては2倍の人手が必要なので影響する
- 本来は1人時間でも、Pivotalは2人時間になってしまう
- 競争力としては支障となる
- この方針を曲げなかった
- 教え合う、成長できる文化に
- 新卒でジュニアな人材を採用しても自然に育成できる環境になった
- ペアプログラミング
ストーリーテリングのポイント
ポイントを絞る
- Etsyの例
- Code as Craft
- コードは工芸品・芸術品
- エンジニアによるアウトプットの公開・共有
- エンジニアとしてマーケターの気分になって多くの人に話す
- エンジニアのチームが毎日ブログで発信する
- Etsyのエンジニアが普段何をしているか
- 条件が箇条書きになっているエンジニアの求人広告はつまらない
- ストーリーを語る求人広告の方が数倍魅力的
- すべての企業にヒーローは必要
- CTOが語るヒーロー（リーダーシップ）の物語
- Code as Craft
皆さんが働きたいと思える物語を語る企業に出会ってください
基調講演2 ポスト・ムーア法則時代のコンピューティング
佐藤一郎 氏
国立情報学研究所 アーキテクチャ科学研究系 教授
ムーア法則の状況
限界が来ている
半導体の企業はムーアの法則を満足するために技術革新を行っていた
- 半導体微細化が1/kになれば、速度はk倍、集積度はk2倍、消費電力は1/k倍になる
- 当初は1年で2倍→18ヶ月で2倍
- 高速化、高機能化、小型化、省電力化、大容量化、低価格化 が実現
- ハードの革新によって、ソフト（アプリ）の性能の悪さは無視できた時代
- 昔はオブジェクト指向言語は性能が悪いと言われていた
- 半導体微細化が1/kになれば、速度はk倍、集積度はk2倍、消費電力は1/k倍になる
ムーアの法則の綻び
ムーアの法則まとめ
- プロセッサの性能は消費電力に依存
- 微細化しても性能はあがりにくい
- プロセッサのコストはリソグラフィ技術に依存
- 微細化してもコストはさがりにくい
- プロセッサの性能は消費電力に依存
1ドルあたりのトランジスタ数は減っている
- 28,14nm以降の微細化で、経済的なメリットがない
フィンテックについて何か話さないと
フィンテックと称される技術で新しい技術は少数
- ブロックチェーンとか
技術的なこととそれ以外を区別すべき
ブロックチェーンのProof of Work（PoW）はコンピュータの性能向上が前提
- ムーア法則の限界はブロックチェーンの限界にもなり得る
- 対策：
- PoW専用マシンを作ってエネルギー効率を上げる
ポスト・ムーア時代に起きること
ポスト・ムーア時代のクラウドビジネス
- クラウドのコスト大半は電力代
- 最新サーバに置き換えても計算量はなかなかあがらない
ポスト・ムーア時代のベンダー＆SI事業者
- IT業界の既存ビジネスモデルは成立しない
- 最新コンピュータに換えても、性能向上しない
- システム更新メリットがなくなる
- ユーザ企業の関心事は、如何に現用ハードウェアを長く使うか、に移る
- 新規事業者には厳しい
- 最新コンピュータに換えても、性能向上しない
ポスト・ムーア時代の性能改善（ハードウェア編）
- 正解は見つかっていない
- 色々な試行錯誤が行われている
- 方向性１：メニーコア化
- 消費電力に限界があるのでクロックを下げないといけない
- 並列化に向かないビジネス的な処理には逆に性能劣化も
- マルチスレッドプログラミングは難しい
- 精鋭プログラマーが必要だし、Testingも難しい
- 方向性２：大容量メモリを活かす
- メモリは活性化があまり行われないので発熱の問題はあまりない
- データをHDD/SSDではなく、メモリに置くことで高速化
- 方向性３：不揮発性メモリの利用
- 方向性４：専用ハードウェア・GPUによるアクセレーター
- 方向性５：分散処理（サーバ台数）でカバー
- 故障の問題
- 世界には２種類のコンピュータしかない
- 壊れたコンピュータ
- いずれ壊れるコンピュータ
- データを複製せよ
- コンピュータが壊れるとデータも失われる
- 読み出しは手近な複製データに行う（処理を分散化）
- 更新の難しさが課題
- 方向性６：Rack−Scale Architecture
方向性７：....
- AI処理向けチップ
- AI処理はそんなに高性能を要求しない、サメの脳みそでもいい
- AI処理向けチップ
ソフトウェア技術者に求められること
結論：余計なトランジスタを使わない
- 適切に無駄な処理をなくす
ソフトウェアによる性能向上
- 科学的に捉える必要性
アルゴリズムの仕組みを理解しているか
- 対象となる処理に対して適切なアルゴリズムを選択・設計しているか
ハードウェアに応じて最適なソフトウェアを作る
ハードウェアやソフトウェアの原理を扱う
コンピュータサイエンスの知見は不可欠
ソフトウェアの性能改善が正当に評価される時代になる
基調講演3 日本の情報システムの未来革新に向けて ～日本の金融業界におけるテクノロジーの可能性と今後の情報システム部門の進むべき道
浦川 伸一 氏
損害保険ジャパン日本興亜株式会社 取締役 常務執行役員
何かにつけて、コードで表すとこのように、と言った感じにコーディングが好きなことが伝わってくる、コードのレベルまで細かく話すかた
Intro
認識している時代背景
- VUCA
- Volatility（変動性）
- Uncertainty（不確実性）
- Complexity（複雑性）
- Ambiguity（曖昧性）
- VUCA
2つの変革
- １．Digital Transformation
- R&D組織を立ち上げ
- ２．Legacy Transformation（今日の主題）
- 合併を重ねて基幹システムがスピード経営の足かせに
- オープン系での刷新を決断
- １．Digital Transformation
現行システムの現状
- Complex
- きめの細かさ
- Fat
- かゆいところに手が届く
- Narrow
- 慎重かつ丁寧な対応
- Complex
→よかれと思ってやってきたことが、この結果
- →この逆をやろう
３つのS
- Simple
- わかりやすい商品・簡素な事務
- 満期を迎えた商品から新しい商品に載せ替え→データ移行をやらないことに
- バッチレス
- わかりやすい商品・簡素な事務
- Slim
- 大幅なサイズダウン
- 手書きコード量の削減
- Speed
- ....
- Simple
Core Architecture
フロント系 ー DB系
- 全体Architectureの検討ポイント
- １．SoR/SoE
- ２．Language Environment
- ３．Microservices
- ４．Framework
- ５．Cloud
１．SoR/SoE
２．Language Environment
３．Microservices
SOAが原型となっている理解
モノリシックなデザインは古い？
何をサービスの単位としてMicroserviceと呼ぶのか、検討中
４．Framework
３つの決定
JavaEEの進化７−＞８，９
５．Cloud
- すでに多数のクラウドサービスを利活用中
- Japan Cloud 日本にデータを置く
情報システム部門の変革
圧倒的な日米格差
- 日本は８：２でITベンダーに依存
- アメリカの比率は逆
- IT部門・IT子会社化がすすむ
ToBE 人材ポートフォリオ
専門職制度導入、専門職のキャリアパス
イノベーションJVの設立（with日立）
ランチセッション オープンソースCMS Drupalの紹介
井村 邦博 氏 株式会社メノックス
（不参加）
昼食後、マクニカネットワークス福留さんに挨拶 CircleCIの Kin さんとも挨拶
A-1 マイクロサービス・アーキテクチャのパターンとベストプラクティス
Patterns & Practices of Microservices
Wesley Reisz 氏 @wesreisz
C4Media社
QCon Product Manager
マイクロサービスアーキテクチャのパターンを紹介
マイクロサービスの名付け親（Adrian Cockcroft、NETFLIX）
"Loosely coupled Service Oriented Architecture with Bounded Contexts"
- 疎結合であること
- 境界があるコンテキスト
- → DDD
Why Microservices？
モノリシックなシステムはモデルが肥大化し、後発のエンジニアが追いつけなくなる
マイクロサービス化を進めることでクラウド化が簡単に出来るようになった
- マイクロサービスは進化するアーキテクチャ
- 万能薬ではない、問題が起こる度に進化し続けなければならない
- 新しい技術を受け入れやすくなる
FIRST PRINCIPLES
DevOps culture is a MUST.
マーティン・ファウラー - 短時間でプロビジョニングができなければいけない - 基本的なモニタリングができなければいけない - 高速にアプリケーションをデプロイできなければいけない
進化し続けるアーキテクチャ
マイクロサービスには常に変化があるから、先にレイヤーの図を描く訳にはいかない
Scale CUBE
- 水平方向のスケール
- 機能の分割
- データのパーティショニング
CAP理論
- Consistency / Partition Tolerance
- Abailability / Partition Tolerance
1. Technical
- TOOLS
- "Everything is a tradeoff just be intentional about them"
ツールに飛びついてはいけない
- SPINE MODEL
- Needs
- まずはニーズを見極めろ、ユーザ・要件を見ろ
- 書き込み要求が高まる箇所と読み込み要求が高まる箇所のバランスをとる
- Values
- Principles
- Practices
- Tools
- Needs
Event Sourcing
- イベント中心のアーキテクチャパターン
- イベントをサブスクライブして、イベント駆動で各機能が処理を行う
非同期でImmustableなState変更
Immutable Events
- Recreate the exact state
- Performance / Load testing
- Increase in complexity
CQRS(コマンドクエリ責務分離)
- サーバの機能をコマンド（副作用あり）とクエリ（副作用なし）で完全に分ける
- Decouple queries from Commands to scale each Service
オペレーションをRead/Writeに分ける
- Read側だけスケールアウトできる
Domain Specific Models
- Scale
CIRCUIT BREAKER
- ダウンしたサービスにアクセスしているサービスがハングする
- ブレーカーを落とす（冷却期間を置く）
- フラグをたてて、一定時間アクセスしないようにする
- 別のサービスを立ち上げ、そちらにアクセスするようにする
- 通常通りのサービスに戻ったら、使うようにする
- Prevents Doomed to Fail
- Three states
- ダウンしたサービスにアクセスしているサービスがハングする
2. Operational
Observability
- Need consistent, structured logging
- Logs are not for humans
- Logstash, Elasticsearch, Kibana works
RPC vs HTTP
- JSON vs Binary
- Speed/Performance vs Readability
Measure serialization, transmission, deserialization costs
Look into:
- Zipkin
- Prometheus
- -> Best way to understand Fanout
- サービスの裏で何が起きているかを把握する
3.Cultural
- Conway's LAW
- Organizations which design systems .. are constrained to produce designs which are copies of the communication structures of the organization.
アーキテクチャには組織が反映される
- Model
- One ....
ちゃんと意図を持った意思決定をする
頭のなかでイメージが整理できる範囲から考え始める
終わりに
先に決定した判断を見直す必要がなければ、あなたはオーバーエンジニアリングしている
A-2 クラウド・ネイティブなデータ・パイプライン
Cloud Native Data Pipelines
Sid Anand 氏 @r39132
Agari
http://www.slideshare.net/r39132/cloud-native-data-pipelines-qcon-shanghai-2016
About Me
AGARIの紹介
- Mailの保護
- BtoC の Consumer Protection を BtoB にも展開中
- eMail の trust score を算出
2種類のデータパイプライン
- BI (Business Integration)
- Analyst 向けDBの提供（非同期）
- Predictive (予測型)
- Data Sourceからリスクモデルを算出してスコアを他のDBへ格納
- リスクのランクごとにWebServiceから参照
- BI (Business Integration)
おすすめコンテンツの抽出
- 各所で使われている技術
Cloud Native Data Pipelines
Quickly Recoverable
- Maintainability
- 壊れても簡単に直せること ＞ 壊れにくい設計にすること
- 想定外の使われ方をすると壊れやすい、それを前提にする必要がある
- 回復時間(MTTR)を短くすることが大切
- Maintainability
Use-Case
Tackling Operability
- Apache Airflow
- Managing DAGs
- Perf. Insights
- Alerting
- Apache Airflow
Use-Case
Apache Avro
QA Time
- Airflow はHA構成に対応していない
- まだ開発者が少なく対応できるリソースがない
- 誰かやってくれ〜PR募集中
A-3 今どきのアーキテクチャ設計戦略
鈴木 雄介 氏
グロースエクスパートナーズ株式会社 アーキテクチャ事業本部 執行役員
http://www.slideshare.net/yusuke/qcon-tokyo-2016
今どきのシステム開発
- 山のようにそびえる基幹システム
波のように日々変化するシステム
SoR(System of Record)
- 情報を正しく記録するためのシステム
- 安全・安心・安定の基幹システム
SoE(System of Engagement)
- 顧客や取引先との「絆」を作るためのシステム
- 最新の状況を表示し、判断してもらうためのシステム
- 機能はユーザごとに最適化され、高頻度で改善されていく
SoE側のシステム
一方で、企業システムとしての制約
- SoEはSoRと必ず連携する
- 基幹システム側は期日ありきで計画主導プロセス
- 社内部門／業務と必ず関わりがある
- 多くのビジネスはITだけで完結しない
- ビジネスは簡単に止められない
- 社会インフラに近いほど「止まっては困る」
- SoEはSoRと必ず連携する
フィードバックと改善
アーキテクチャ設計基礎
- アーキテクチャ＝システムの分け方と組み方（by ISO）
- システムのミッションに従い
- システムの置かれた制約と前提としながら
- システムに関わる複数の利害関係者の関心事を整合させ、
- ライフサイクル（設計から保守）まで意識した
- システムの分け方と組み方のこと
遊星歯車
「振る舞い」と「構造」
- 振る舞い
- 機能と非機能
- 構造
- 動的構造と静的構造
- 振る舞い
アーキテクチャ設計
- ある振る舞いを実現する構造を導く作業
- 「振る舞いへの要求」を理解して構造を定義する
- 「システムの設計や実装」は事前に決められた定義に従う
- ある振る舞いを実現する構造を導く作業
アーキテクチャ設計の理想的な進め方
- 必要な振る舞いを定義し、それに対する構造を設計する
- 振る舞いが正確に定義できているほど、適切な設計を行える
- 実装が始まる前までに、すべての要求が明確で、それに対して最適な構造が定義される
- 必要な振る舞いを定義し、それに対する構造を設計する
今どきのアーキテクチャ設計
アーキテクチャ設計のジレンマ
- 要求が曖昧では構造が定義できない
- 振る舞いを見ないと要求が分からない
- 構造がないと振る舞いを実現できない
SoEでは正しい要求が先にない
変更に対応する構造を作れるか？
- 初期段階では最適な構造を確定できない
- 必要な機能が段階的に足されていく
- なんらかのアーキテクチャ設計戦略が必要になる
- 予測型、犠牲型、拡張型
予測型
- 追加される機能に対して同一の構造を割り当てる
- 予測が正しければ、の話
- 追加される機能に対して同一の構造を割り当てる
予測増改築型
- 予測を長期間維持してこじらせたパターン
- 保守性が悪く、コストが増加する（別名：温泉旅館型）
- 予測を長期間維持してこじらせたパターン
犠牲型
- 最初に作る構造は最低限にしておき、のちに再整備する
- 技術的負債をガツッと返済するパターン
- 機能移植にコストはかかるが長期間維持できる
- 最初に作る構造は最低限にしておき、のちに再整備する
拡張型
- 構造そのものに拡張性を持たせる
- ※天才に限る
- Eclipse（plug-in構造）は15年以上続いている構造
- ※天才に限る
- 構造そのものに拡張性を持たせる
設計戦略の整理
- そもそも「予測型」には限界がある
- いつでも「犠牲型」になる覚悟は必要
- とはいえ毎回犠牲型とは言い難い
- 「拡張型」をベースにしていく
- 自分で作らず、他人が作った拡張構造を利用する
他人が作った拡張構造に頼る
サーバーレスアーキテクチャ
- コードを配置するだけで実行される
- インフラのマネジメント不要でオートスケール
- シェルっぽいもの、トリガーやタイマーのような位置づけとしていい
- 処理内容には制約がある
- 使い過ぎはピタゴラスイッチ状態になるので注意
機能ごとに最適な構造を用意するのは無駄か？
拡張型×犠牲型
- 基本構造を変えずに、必要に応じて拡張・再構築していく
その集大成がマイクロサービスアーキテクチャ
マイクロサービスアーキテクチャ
メリット
- モノリシックなシステムでは変更が全体に影響する
カナリアリリース
- Blue−Greenで徐々に移行させる
いかにサービスを管理するのか
疎結合を維持する
知的なルーター
- Eureka+Ribbon的なもの
サーキットブレーカー
- 階層型障害への対応
- 自分の身は自分で守る
- 異常処理への対応
- タイムアウト時のリトライやエラー処理
- 階層型障害への対応
分散トレース
- サービスを横断したログのトレース
障害注入テスト
- Chaos Monkey
- 平日日中にサーバをランダムにダウンさせるためのOSS
マイクロサービスプラットフォーム製品
- Spring Cloud
ツール群
- CI/CD
エンタープライズ適用
- 本質：サービス同士を疎結合にして個別変更を許容する
- サービスの大きさを気にしすぎない
- 品質の考え方について整理すること
- サービス全体を保護するために小さな障害を許容する
- 明日からでも始めるべき
- 今のシステムから1つ目のサービスを切り出せるか
- 「マイクロサービスで全体を再構築」はうまくいかない
- 本質：サービス同士を疎結合にして個別変更を許容する
アーキテクトの役割
プラットフォームの選択は重要
- 自らのドメインに適用できるか
アーキテクトがいるのは塔か現場か
- 塔の上から俯瞰するvs現場の関心事を解決する
休憩 & 展示 & ライトニングトーク
太田 昌文 氏「RaspberryPi最新動向」
（不参加）
A-4 サーバーレス・アーキテクチャ
伊藤 直也 氏
株式会社 一休 執行役員 CTO
https://speakerdeck.com/naoya/serverless-architecture
結論
サーバーレス
- Shared Nothing
- 必要になったときだけ計算
- イベント駆動
- Reactive
- Microservices
- オーケストレーションからコレオグラフィへ
- イベント駆動
- 必要になったときだけ計算
- Shared Nothing
サーバーレスアーキテクチャとは
2つの「サーバーレス」
- ハードウェア的意味での「サーバー」がない
- 常駐プロセス的な意味での「サーバー」がない
- Function as a Service（FaaS）の話
- 今日は主にこちらの話
AWS Lambda
- serverless framework を利用
$ serverless deploy
Lambda ファンクションはサーバーレスで実行される
- コンテナで実行される
- コンテナは実行時に作成され、終了時に破棄される
- 常駐プロセスではない。CGIに近いモデル
Lambdaファンクションはステートレスである
- ステートを保持できない
- ステートレス（Shared Nothing）
- 何か問題が怒っても、別の実行には悪影響を与えない
- スケールしたかったらもっと起動すればいい
AWS Lambdaはスケールするし、安い
- イベント量に合わせてLambdaが自動でスケール
- ステートレスなのでスケールしやすい
- プロセスが落ちてた。。。なんてことがない。安全
- 計算した分しか費用はかからない
- EC2を立ち上げっぱなしにするのにくらべ、かなりお得
- イベント量に合わせてLambdaが自動でスケール
サーバーレスアーキテクチャ
- ごく単純化するとFaaSを利用したシステム設計アーキテクチャ
利用事例
FaaSでイベント駆動設計を突き詰めておくと、自ずとマイクロサービスが見えてくる
CGIはリクエストごとに実行、終わったら破棄
- アプリケーション全体を毎回 fork がとても非効率
- 常駐プロセス prefork ・・・プロセスを作っておいて常駐
- オーバーヘッドが少なく安全だが、並行性能に難
- スケーラビリティに難
- メモリフットプリントが大きい。
- プロセス数が最大同時接続数を決めてしまう（C10K問題）
- イベント駆動モデルによる並行処理
- like Node.js
- 並行性能が高いが可用性に難
起動に伴うオーバーヘッドが少なければ、毎回実行で構わないのでは・・・
- これがLambda
Shared Nothing という制約
イベントへの反応として処理を記述する
- 結果、サービスは疎結合に
Reactive マニフェスト
- メッセージ駆動(Message-Driven)
- 伸縮性(Elastic)
- 対障害性(Resirience)
- 高レスポンス(High response)
- メッセージ駆動(Message-Driven)
それぞれのLambdaはマイクロな関数になる
- 小さな（マイクロな）関数をイベントで（疎結合に）組み合わせる
- FaaSは自然とマイクロサービスを指向する
オーケストレーション vs コレオグラフィ
- オーケストレーション
- オーケストラによる演奏方法
- 中央の指揮者がサービスの呼び出しをコントロールし、ビジネスプロセスの実行を指揮する
- リクエスト・リプライ
- サブルーチン呼び出し・メソッドインヴォケーション
- コレオグラフィ
- バレーや舞踏などのダンサーへの振り付け
- サービスの呼び出しをコントロールしたり、ビジネスプロセスの実行を指揮する存在はいない
- イベント駆動
- イベントを投げる人とサブスクライブする人に直接の依存関係がない
- オーケストレーションに比べて自律的
- オーケストレーション
スターバックスは2フェーズコミットを使わない
- レジの人がすべてのミッション完了を待たない
- これはオーケストレーションではなくコレオグラフィ
- この方がスループットが最大化される
マイクロサービスを指向するならコレオグラフィ
- 非同期のイベント連携
- 大幅に分離されたサービスを生み出せる
- 非同期のイベント連携
FaaSは自然とコレオグラフィを指向する
ぶっちゃけどうなの？
FaaSを用いたサーバーレスアーキテクチャは、マイクロサービスの具体的な実現手段の一つ
どういう時に使うの？
サーバーレスの今後
C-5 DevOps導入&実践の落とし穴 - Disciplined DevOpsに見る体系的アプローチ
藤井 智弘 氏
日本ヒューレット・パッカード株式会社
Disciplined Agile
