読者です 読者をやめる 読者になる 読者になる

Logic Delight

明日のワシは忘れてしまうから、コードにはコメントを書くのです。

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はマネージャーの比率は非常に少ない
    • マネージャーが少ないということは、自分で頭を使える自律性のある人を雇わなければならない
  • Googleは実験をすることを好む
    • 20%ルール
      • 毎週1日は好きなことができる
    • 多くのイノベーティブなプロダクトは20%ルールから生まれた
      • インスピレーションは、自由な発想から生まれる
    • 他の企業も少なからず20%ルールに近いものを導入しようとしている
      • ハッカソンでいつもと違うチームで何か意味が無いかもしれないことに取り組む
    • エンジニアに自律性を生ませる
  • トレード・オフはある
    • Googleは非常に大きな企業
      • Alphabetという企業に作り直した
      • 自分自身の文化を一旦、破壊することも重要
      • 文化を変えるために必要

インパクトを与える』

  • facebookは映画化された、内容は非常に正確
    • facebookという文化がどうやって作られたか
    • マーク・ザッカーバーグは、自分がやろうとしていることを阻害するものを予見して、先手を取って阻害するものに対応していた
    • これから先あるだろうハードルを、早い段階で飛び越える
    • 速く進んで、色んな物を壊す、という文化
    • 入社後すぐに、1日3回リリーストレインとしてリリースする
      • エンジニアとしてすぐに本番環境に影響することができる
      • facebookはあまりQAしない
        • 新しい機能は、まず社内で試験運用される
    • 入社して2日目でリリーストレインに乗せることを期待される
      • エンジニアは大きくエキサイトする
    • もちろんトレードオフはある
      • 私のモットーは "Move Fast AND Break Things."
      • facebookザッカーバーグは、迅速に動いてStableなインフラを持ち続けること、とある時に言った
      • 破壊を限定的にするメッセージ(文化を変える)を伝えた

『Ownership』

  • Etsy

    • 手作りのものだけを売るマーケットプレイス
    • ユーザの文化と結びついている
      • 自分で構築し、自分で運用してください
    • 自分が書いたコードがうまく動かなかったとき、自分で責任を持ってなんとかしないといけない
      • Ownershipを重視する
      • 他の人・QAに頼らない
      • コードをリリースする前にチェックリストを自分で確認する
      • 自分のコードを書いて所有することにプライドを持つ文化
  • NETFLIX

    • クラウド上で完全に運用している最大の企業
    • モノリシックなアプリケーションだった
      • 大きな障害が発生し、3日間Downした
      • エンジニアを集めて、これが2度と起こらないようにしよう、と話し合う
      • モノリシックなアーキテクチャを分解する
      • マイクロサービス化する方向へ
    • 30以上のチームが、それぞれのサービスを担当
      • 各サービス担当者が自サービスへの責任を強く持つ
      • 組織の文化を変えるきっかけに

『学習(Learning)』

エンジニアは誰も学習に意欲的

  • Pivotal Labs
    • 学習を全く新しい次元に引き上げた企業
    • XP を採用
      • ペアプログラミング
        • 2人のエンジニアが常に一緒に仕事をする
        • お互いのコードを見て意見を出し合う
      • Pivotalはこのモデルにコミットしている
      • ビジネスにとっては2倍の人手が必要なので影響する
        • 本来は1人時間でも、Pivotalは2人時間になってしまう
        • 競争力としては支障となる
      • この方針を曲げなかった
      • 教え合う、成長できる文化に
      • 新卒でジュニアな人材を採用しても自然に育成できる環境になった

ストーリーテリングのポイント

ポイントを絞る

  • Etsyの例
    • Code as Craft
      • コードは工芸品・芸術品
    • エンジニアによるアウトプットの公開・共有
      • エンジニアとしてマーケターの気分になって多くの人に話す
      • エンジニアのチームが毎日ブログで発信する
        • Etsyのエンジニアが普段何をしているか
    • 条件が箇条書きになっているエンジニアの求人広告はつまらない
      • ストーリーを語る求人広告の方が数倍魅力的
    • すべての企業にヒーローは必要
      • CTOが語るヒーロー(リーダーシップ)の物語

皆さんが働きたいと思える物語を語る企業に出会ってください

基調講演2 ポスト・ムーア法則時代のコンピューティング

佐藤一郎
国立情報学研究所 アーキテクチャ科学研究系 教授

ムーア法則の状況

限界が来ている

  • 半導体の企業はムーアの法則を満足するために技術革新を行っていた

    • 半導体微細化が1/kになれば、速度はk倍、集積度はk2倍、消費電力は1/k倍になる
      • 当初は1年で2倍→18ヶ月で2倍
    • 高速化、高機能化、小型化、省電力化、大容量化、低価格化 が実現
    • ハードの革新によって、ソフト(アプリ)の性能の悪さは無視できた時代
  • ムーアの法則の綻び

    • 微細化のスローダウンが進行中
      • Intelも36ヶ月で2倍
    • 3つの限界
      • 半導体製造技術的な限界
      • 電力的な限界★
        • スケーリング則の破綻
          • 集積化しても消費電力あたりの計算量が上がらない
        • ダークシリコンの増加
          • 発熱を考えると消費電力が100Wを超えるチップは作れない
      • 経済的な限界★
        • 半導体工場の建設費コストの巨額化
          • 14nmクラスの半導体工場は1兆円越え
          • 製造最小ロットの増大
  • ムーアの法則まとめ

    • プロセッサの性能は消費電力に依存
      • 微細化しても性能はあがりにくい
    • プロセッサのコストはリソグラフィ技術に依存
      • 微細化してもコストはさがりにくい
  • 1ドルあたりのトランジスタ数は減っている

    • 28,14nm以降の微細化で、経済的なメリットがない

フィンテックについて何か話さないと

  • フィンテックと称される技術で新しい技術は少数

    • ブロックチェーンとか
  • 技術的なこととそれ以外を区別すべき

  • ブロックチェーンのProof of Work(PoW)はコンピュータの性能向上が前提

    • ムーア法則の限界はブロックチェーンの限界にもなり得る
    • 対策:
      • PoW専用マシンを作ってエネルギー効率を上げる

ポスト・ムーア時代に起きること

  • 半導体技術を前提にしたコンピュータの高性能化が期待できない時代

    • 今、遅いソフトウェアは、ずっと遅い
  • Intel Xeonは性能向上を続けられるか

    • Xeonは複雑な回路であり、微細化しても消費電力は大きく下がらない
    • 限界が最も近い

ポスト・ムーア時代のクラウドビジネス

  • クラウドのコスト大半は電力代
  • 最新サーバに置き換えても計算量はなかなかあがらない

ポスト・ムーア時代のベンダー&SI事業者

  • IT業界の既存ビジネスモデルは成立しない
    • 最新コンピュータに換えても、性能向上しない
      • システム更新メリットがなくなる
    • ユーザ企業の関心事は、如何に現用ハードウェアを長く使うか、に移る
      • 新規事業者には厳しい

ポスト・ムーア時代の性能改善(ハードウェア編)

  • 正解は見つかっていない
    • 色々な試行錯誤が行われている
    • 方向性1:メニーコア化
      • 消費電力に限界があるのでクロックを下げないといけない
      • 並列化に向かないビジネス的な処理には逆に性能劣化も
      • マルチスレッドプログラミングは難しい
    • 方向性2:大容量メモリを活かす
      • メモリは活性化があまり行われないので発熱の問題はあまりない
      • データをHDD/SSDではなく、メモリに置くことで高速化
    • 方向性3:不揮発性メモリの利用
      • 不揮発性メモリ(NvRAM)
      • MRAMやReRAM、HDD/SSDと比べて高速でDRAMよりも容量が大きい
    • 方向性4:専用ハードウェア・GPUによるアクセレーター
    • 方向性5:分散処理(サーバ台数)でカバー
      • 故障の問題
      • 世界には2種類のコンピュータしかない
        • 壊れたコンピュータ
        • いずれ壊れるコンピュータ
      • データを複製せよ
        • コンピュータが壊れるとデータも失われる
      • 読み出しは手近な複製データに行う(処理を分散化)
      • 更新の難しさが課題
    • 方向性6:Rack−Scale Architecture
    • 方向性7:....

      • AI処理向けチップ
        • AI処理はそんなに高性能を要求しない、サメの脳みそでもいい

ソフトウェア技術者に求められること

結論:余計なトランジスタを使わない

  • 適切に無駄な処理をなくす
  • ソフトウェアによる性能向上

    • 科学的に捉える必要性
  • アルゴリズムの仕組みを理解しているか

    • 対象となる処理に対して適切なアルゴリズムを選択・設計しているか
  • ハードウェアに応じて最適なソフトウェアを作る

  • ハードウェアやソフトウェアの原理を扱う

  • コンピュータサイエンスの知見は不可欠

  • ソフトウェアの性能改善が正当に評価される時代になる

基調講演3 日本の情報システムの未来革新に向けて ~日本の金融業界におけるテクノロジーの可能性と今後の情報システム部門の進むべき道

浦川 伸一 氏
損害保険ジャパン日本興亜株式会社 取締役 常務執行役員

何かにつけて、コードで表すとこのように、と言った感じにコーディングが好きなことが伝わってくる、コードのレベルまで細かく話すかた

Intro

  • 認識している時代背景

    • VUCA
      • Volatility(変動性)
      • Uncertainty(不確実性)
      • Complexity(複雑性)
      • Ambiguity(曖昧性)
  • 2つの変革

    • 1.Digital Transformation
      • R&D組織を立ち上げ
    • 2.Legacy Transformation(今日の主題)
      • 合併を重ねて基幹システムがスピード経営の足かせに
      • オープン系での刷新を決断
  • 現行システムの現状

    • Complex
      • きめの細かさ
    • Fat
      • かゆいところに手が届く
    • Narrow
      • 慎重かつ丁寧な対応
  • →よかれと思ってやってきたことが、この結果

    • →この逆をやろう
  • 3つのS

    • Simple
      • わかりやすい商品・簡素な事務
        • 満期を迎えた商品から新しい商品に載せ替え→データ移行をやらないことに
      • バッチレス
    • Slim
      • 大幅なサイズダウン
      • 手書きコード量の削減
    • Speed
      • ....

Core Architecture

フロント系 ー DB系

  • 全体Architectureの検討ポイント
    • 1.SoR/SoE
    • 2.Language Environment
    • 3.Microservices
    • 4.Framework
    • 5.Cloud

1.SoR/SoE

2.Language Environment

  • Javaか?

    • せいぜい言語の中で22%
    • デファクトとなったJava
    • 決して可読性の良い言語ではない
  • Pythonは簡潔で好き

3.Microservices

4.Framework

5.Cloud

  • すでに多数のクラウドサービスを利活用中
  • Japan Cloud 日本にデータを置く

情報システム部門の変革

ランチセッション オープンソースCMS Drupalの紹介

井村 邦博 氏 株式会社メノックス

(不参加)

昼食後、マクニカネットワークス福留さんに挨拶 CircleCIの Kin さんとも挨拶

A-1 マイクロサービス・アーキテクチャのパターンとベストプラクティス

Patterns & Practices of Microservices
Wesley Reisz 氏 @wesreisz
C4Media社

QCon Product Manager

  • マイグレーション
    • 4年前、TomcatJavaアプリケーション
      • スケールアップ・スケールアウト
      • DBがFat化(スケールアップ)
    • 2年前、Cold / Hot構成にシステムを2分化
      • Reporting用DBの導入
    • Hot / Hot構成へ
    • クラウド環境への移行
      • 多数のアプリケーション
      • マイクロサービスアーキテクチャの基本的な要素が欠けていた

マイクロサービスアーキテクチャのパターンを紹介

マイクロサービスの名付け親(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

アーキテクチャパターン

  • 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から参照
  • おすすめコンテンツの抽出

    • 各所で使われている技術
  • Cloud Native Data Pipelines

    • 大手の技術企業は自社内でデータパイプラインを構築している
    • 大半のスタートアップはデータパイプラインをクラウド上で構築する必要がある

    • Correctness

      • Data Integrity
      • Expected data distributions
    • Timeliness
      • All output within time-bound SLAs
    • Operability
      • Fine-grained Monitoring & Alerting of Correctness & Timeliness SLAs
      • Quick Recoverability
    • Cost
      • Pay-as-you-go
  • Quickly Recoverable

    • Maintainability
      • 壊れても簡単に直せること > 壊れにくい設計にすること
      • 想定外の使われ方をすると壊れやすい、それを前提にする必要がある
      • 回復時間(MTTR)を短くすることが大切
  • Use-Case

    • Message Scoring
      • S3ストアされた大量のデータソースをもとにApache Airflow(Spark)でスコアリングし、別のS3に保存し、SNS/SQSで配信する
      • このバッチ処理は、1日の中で1時間しか動かない
      • EC2で構築すれば23時間分はコスト削減になる
      • ASG(Auto Scaling Group)で処理の流量に応じてCPU使用率が一定になるよう自動スケールさせる
  • Tackling Operability

    • Apache Airflow
      • Managing DAGs
      • Perf. Insights
      • Alerting
  • Use-Case

    • Message Scoring(Near Realtime)
      • Kinesisに大量データを投入、ASGでスコアリングして、結果をKinesisへ、KinesisインポータでDBに登録すると並行してKinesis経由でAlert通知
  • Apache Avro

    • self-describing serialization format that supports
      • primitive data types
      • complex data types
      • many language bindings
    • テーブルの中でスキーマ情報が99%で実データが1%のような構成はOverheadが高い
    • Schema Registry(Lambda)を使ってMessage Sizeを削減
    • スキーマを一意のハッシュKeyで登録、各メッセージはSchemaハッシュのみを格納する

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型には「正しい仕様」は存在しない
      • 社内には「本当のユーザー」がいない
    • 仮説検証型の進め方にするしかない
      • 「仮説としての仕様」から始まる
  • 一方で、企業システムとしての制約

    • SoEはSoRと必ず連携する
      • 基幹システム側は期日ありきで計画主導プロセス
    • 社内部門/業務と必ず関わりがある
      • 多くのビジネスはITだけで完結しない
    • ビジネスは簡単に止められない
      • 社会インフラに近いほど「止まっては困る」
  • フィードバックと改善

    • SoEではフィードバックと改善のリズムを作ることが大事
      • リズムの速さは「ビジネスによる」で問題ない
    • どうやって継続的に機能を追加していくのか
      • アジャイルとかWFの議論ではない
      • 時間制限の中でやる仕事、と、終わるまでやるべき仕事

アーキテクチャ設計基礎

  • アーキテクチャ=システムの分け方と組み方(by ISO)
    • システムのミッションに従い
    • システムの置かれた制約と前提としながら
    • システムに関わる複数の利害関係者の関心事を整合させ、
    • ライフサイクル(設計から保守)まで意識した
    • システムの分け方と組み方のこと

遊星歯車

  • 「振る舞い」と「構造」

    • 振る舞い
      • 機能と非機能
    • 構造
      • 動的構造と静的構造
  • アーキテクチャ設計

    • ある振る舞いを実現する構造を導く作業
      • 「振る舞いへの要求」を理解して構造を定義する
      • 「システムの設計や実装」は事前に決められた定義に従う
  • アーキテクチャ設計の理想的な進め方

    • 必要な振る舞いを定義し、それに対する構造を設計する
      • 振る舞いが正確に定義できているほど、適切な設計を行える
    • 実装が始まる前までに、すべての要求が明確で、それに対して最適な構造が定義される

今どきのアーキテクチャ設計

  • アーキテクチャ設計のジレンマ

    • 要求が曖昧では構造が定義できない
    • 振る舞いを見ないと要求が分からない
    • 構造がないと振る舞いを実現できない
  • SoEでは正しい要求が先にない

  • 変更に対応する構造を作れるか?

    • 初期段階では最適な構造を確定できない
    • 必要な機能が段階的に足されていく
    • なんらかのアーキテクチャ設計戦略が必要になる
      • 予測型、犠牲型、拡張型
  • 予測型

    • 追加される機能に対して同一の構造を割り当てる
      • 予測が正しければ、の話
  • 予測増改築型

    • 予測を長期間維持してこじらせたパターン
      • 保守性が悪く、コストが増加する(別名:温泉旅館型)
  • 犠牲型

    • 最初に作る構造は最低限にしておき、のちに再整備する
      • 技術的負債をガツッと返済するパターン
      • 機能移植にコストはかかるが長期間維持できる
  • 拡張型

    • 構造そのものに拡張性を持たせる
      • ※天才に限る
        • Eclipse(plug-in構造)は15年以上続いている構造
  • 設計戦略の整理

    • そもそも「予測型」には限界がある
    • いつでも「犠牲型」になる覚悟は必要
      • とはいえ毎回犠牲型とは言い難い
    • 「拡張型」をベースにしていく
      • 自分で作らず、他人が作った拡張構造を利用する
  • 他人が作った拡張構造に頼る

    • OSSフレームワークを利用する
    • コミュニティが蓄積しているノウハウに頼る

      • ex.) Spring Security
        • 認証と認可に関する基本的な機能があり、自分で拡張できる構造になっている
    • クラウドサービスを利用する

      • 利用すべきはPaaS
      • パターンに従って実装することで構造が拡張される
    • 構造だけではなく非機能要件まで含めて構造が保証する
      • PaaSの進化
  • サーバーレスアーキテクチャ

    • コードを配置するだけで実行される
    • インフラのマネジメント不要でオートスケール
      • シェルっぽいもの、トリガーやタイマーのような位置づけとしていい
    • 処理内容には制約がある
    • 使い過ぎはピタゴラスイッチ状態になるので注意
  • 機能ごとに最適な構造を用意するのは無駄か?

    • 技術の成熟に伴い、ニッチな構造が増えている
      • ビッグデータ:大規模分散処理
      • リアルタイム処理:ストリーミング処理
      • スケールするデータストア:NoSQL
      • 検索
    • すべてOSSでもPaaSでも利用可能
  • 拡張型×犠牲型

    • 基本構造を変えずに、必要に応じて拡張・再構築していく
  • その集大成がマイクロサービスアーキテクチャ

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

  • メリット

    • モノリシックなシステムでは変更が全体に影響する
  • カナリアリリース

    • Blue−Greenで徐々に移行させる
  • いかにサービスを管理するのか

    • ドメインは重要だが、正解はない
    • NETFLIXのトップページでは500個のサービスが動く
  • 疎結合を維持する

    • データ分離
      • イベントソーシング(CQRS)
    • テスト戦略
      • Test Doubles
        • テストを動かすのは大変なのでスタブやモック
      • Dark Canaries
        • 本番環境上に開発者用のテスト版をリリース
        • 本物を使ってテストする(ただし、できないものもある)
      • Consumer-Driven Contract testing
        • コンシューマーが要求するCPI挙動を契約として定義し、プロバイダが契約を検証して破壊的変更を防ぐ
    • 不整合の許容
      • Amazonのクーポン」
      • 非同期メッセージによる不整合を許容する
        • データのリアルタイムな整合性を捨てることの金銭的価値
  • 知的なルーター

  • サーキットブレーカー

    • 階層型障害への対応
      • 自分の身は自分で守る
    • 異常処理への対応
  • 分散トレース

    • サービスを横断したログのトレース
  • 障害注入テスト

    • Chaos Monkey
    • 平日日中にサーバをランダムにダウンさせるためのOSS
  • マイクロサービスプラットフォーム製品

    • Spring Cloud
  • ツール群

    • CI/CD
  • エンタープライズ適用

    • 本質:サービス同士を疎結合にして個別変更を許容する
      • サービスの大きさを気にしすぎない
    • 品質の考え方について整理すること
      • サービス全体を保護するために小さな障害を許容する
    • 明日からでも始めるべき
      • 今のシステムから1つ目のサービスを切り出せるか
      • 「マイクロサービスで全体を再構築」はうまくいかない

アーキテクトの役割

  • プラットフォームの選択は重要

  • アーキテクトがいるのは塔か現場か

    • 塔の上から俯瞰するvs現場の関心事を解決する

休憩 & 展示 & ライトニングトーク

太田 昌文 氏「RaspberryPi最新動向」

(不参加)

A-4 サーバーレス・アーキテクチャ

伊藤 直也 氏
株式会社 一休 執行役員 CTO

https://speakerdeck.com/naoya/serverless-architecture

  • 結論

    • サーバーレスアーキテクチャとは
      • 単純にはFaaSを使ったシステム
      • ステートレスなFaaSがリアクティブ、マイクロサービス、コレオグラフィへと導く
    • 現場感覚では「運用が楽でスケールして、安い」
    • 銀の弾丸ではないが、応用領域は広がると思われる
    • ちょっとしたタスクをこなすためや、マイクロサービスの実現手段として、引き出しの一つに入れておいて損はない
  • サーバーレス

    • Shared Nothing

サーバーレスアーキテクチャとは

  • 2つの「サーバーレス」

    • ハードウェア的意味での「サーバー」がない
    • 常駐プロセス的な意味での「サーバー」がない
      • Function as a Service(FaaS)の話
      • 今日は主にこちらの話
  • AWS Lambda

    • serverless framework を利用
    • $ serverless deploy
  • Lambda ファンクションはサーバーレスで実行される

    • コンテナで実行される
    • コンテナは実行時に作成され、終了時に破棄される
    • 常駐プロセスではない。CGIに近いモデル
  • Lambdaファンクションはステートレスである

    • ステートを保持できない
    • ステートレス(Shared Nothing)
      • 何か問題が怒っても、別の実行には悪影響を与えない
      • スケールしたかったらもっと起動すればいい
  • AWS Lambdaはスケールするし、安い

    • イベント量に合わせてLambdaが自動でスケール
      • ステートレスなのでスケールしやすい
      • プロセスが落ちてた。。。なんてことがない。安全
    • 計算した分しか費用はかからない
      • EC2を立ち上げっぱなしにするのにくらべ、かなりお得
  • サーバーレスアーキテクチャ

  • 利用事例

    • AWS S3にアップロードされた画像のサムネイル画像を非同期で作成

      • イベント(JSON形式)駆動
    • エンジニアの書類選考をSlackに通知

      • Redmine -> AmazonAPI Gateway -> Lambda -> Slack通知
        • 以前はHeroku Bot を常駐させて通知していた
    • 行動ログ収集 & 分析

      • Appサーバ(fluentd) -> Kinesis -> Lambda -> S3 -> Lambda -> GoogleBigQuery
    • 紙面ビューアーを支えるサーバーレスアーキテクチャ(by日経新聞

      • 複数のLambdaが連動して処理
  • FaaSでイベント駆動設計を突き詰めておくと、自ずとマイクロサービスが見えてくる

  • CGIはリクエストごとに実行、終わったら破棄

    • アプリケーション全体を毎回 fork がとても非効率
  • 常駐プロセス prefork ・・・プロセスを作っておいて常駐
    • オーバーヘッドが少なく安全だが、並行性能に難
    • スケーラビリティに難
      • メモリフットプリントが大きい。
      • プロセス数が最大同時接続数を決めてしまう(C10K問題)
  • イベント駆動モデルによる並行処理
    • like Node.js
    • 並行性能が高いが可用性に難
  • 起動に伴うオーバーヘッドが少なければ、毎回実行で構わないのでは・・・

    • これがLambda
  • Shared Nothing という制約

  • イベントへの反応として処理を記述する

  • Reactive マニフェスト

    • メッセージ駆動(Message-Driven)
      • 伸縮性(Elastic)
      • 対障害性(Resirience)
        • 高レスポンス(High response)
  • Erlang VM

    • ErlangVM は非常に小さい → 高速に起動できる
    • 起動が十分に高速なら、都度実行すればいい、の例
  • それぞれのLambdaはマイクロな関数になる

    • 小さな(マイクロな)関数をイベントで(疎結合に)組み合わせる
    • FaaSは自然とマイクロサービスを指向する
  • オーケストレーション vs コレオグラフィ

    • オーケストレーション
      • オーケストラによる演奏方法
      • 中央の指揮者がサービスの呼び出しをコントロールし、ビジネスプロセスの実行を指揮する
      • リクエスト・リプライ
        • サブルーチン呼び出し・メソッドインヴォケーション
    • コレオグラフィ
      • バレーや舞踏などのダンサーへの振り付け
      • サービスの呼び出しをコントロールしたり、ビジネスプロセスの実行を指揮する存在はいない
      • イベント駆動
  • スターバックスは2フェーズコミットを使わない

  • マイクロサービスを指向するならコレオグラフィ

    • 非同期のイベント連携
      • 大幅に分離されたサービスを生み出せる
  • FaaSは自然とコレオグラフィを指向する

  • ぶっちゃけどうなの?

  • FaaSを用いたサーバーレスアーキテクチャは、マイクロサービスの具体的な実現手段の一つ

  • どういう時に使うの?

    • 小さなユースケースでは積極的に使えばいい
    • 大きなユースケースではいつ使うのか・・・まだ言語化できてない
      • オーバーヘッドは比較的小さいがゼロではない
    • サーバーレスとそうじゃないのを組み合わえる事例が増えてる
  • サーバーレスの今後

C-5 DevOps導入&実践の落とし穴 - Disciplined DevOpsに見る体系的アプローチ

藤井 智弘 氏
日本ヒューレット・パッカード株式会社

Disciplined Agile

  • DevOpsが腹落ちしない

    • 共通定義が難しい(ひとりひとりのDevOpsが違う)
    • 関係者ごとに目線・目的が異なる
  • 海外では Agile が有効活用され活況

  • 日本では

    • 強いベンダー依存
    • 異なる体制
    • "しきたり"駆動
    • コスト < キャッシュアウト
  • DevOpsの前に DAD

    • Disciplined Agile Delivery
    • DAD の基礎
      • SCRUM の拡張
      • ステークホルダーがどうやって合意形成しながらプロジェクトを進めていくか
      • ゴール駆動アプローチ
  • Disciplined DevOps 導入におけるDAの位置づけ

    • DevOps 以前に Agile ができていない
  • 継続的改善のために

    • IT4IT
    • IT Value Chain