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

Logic Delight

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

携帯のメールアドレスに迷惑メールが来たので通報した2

今回のメールはこんな感じ。

差出人:   <j0a7mwgs7@i.softbank.jp>
日時: 2016年10月19日 19:32:43 JST
宛先: (ワシの携帯メールアドレス)
件名: 【速報】大切なお知らせ(19時32分)


大切なお知らせが御座いますのでご連絡差し上げました。
誠に恐れ入りますが、速やかに通知内容をご確認下さい。

●通知先
(ワシの携帯メールアドレス)

●通知内容
http://vv.wefravs5g.com/bin/campX.php?{怪しいパラメータが沢山}
●期限日時
2016年10月20日木曜日
07時32分35秒迄

何卒、宜しくお願い申し上げます。

------
個人情報を保護する為、メール本文に詳細を記載しておりませんが、
URL(リンク)先は受取人の為の特別な秘密情報を含んでいます。
大切なお知らせの為、通常受信していない場合でも配信しております。
尚、当メールは送信用途のみで使用しており、直接返信されましても確認しておりません。

ご理解・ご協力の程お願い致します。

何者かも名乗らずに、さも大事のように「大切なお知らせ」を伝えたがる連中。通知内容のURLパラメータの多さがウケるw そんな大事なことは、こんな胡散臭いメールでは通知せんわ!

ということで、前回同様に通報しました。

@2016/10/27追記
読者のどなたかが引用メールにあるURLにアクセスしたからか、続きのメールが届き始めたのでURLパラメータをごっそりマスクしました。

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

AWS ソリューション Day 2016 セキュリティ&コンプライアンス

AWS ソリューション Day 2016 セキュリティ&コンプライアンス

日時: 2016 年 8 月 31 日(水) 9:30-16:30
会場: ソラシティ カンファレンスセンター(東京/御茶ノ水
来場: 参加無料(要事前申込)
定員: 330名

https://aws.amazon.com/jp/solutiondays20160831/

10:00-10:05 オープニング 長崎 忠雄

(アマゾン ウェブ サービス ジャパン株式会社 代表取締役社長)

現在13リージョン→今年中に17リージョン
シンガポールの銀行(DBS)が情報資産の50%をAWS化を決定
 →世界中の金融機関から問い合わせが殺到

10:05-10:45 基調講演:クラウドサービスセキュリティの国際規格 ~利用者責任と監査の活用~ 永宮 直史

(日本セキュリティ監査協会(JASA) クラウドセキュリティ推進協議会 事務局長)

  • 政府統一基準におけるクラウド利用の基準

    1. 情報の格付けに従ったクラウドサービス利用の判断
    2. 外国法が利用されるリスクの評価
    3. サービス中断時・終了時の円滑な業務の移管
    4. ベンダーロックインをさせないルール・独自仕様の回避・利用者情報取得の自由
    5. 情報流通経路全般にわたったセキュリティ設計・セキュリティ要件
    6. 監査報告の内容や認証制度の適応状況を踏まえた事業者の信頼性の評価
  • 監査にする記載(ガイドP118)

  • ISO/IEC27017

    • 情報セキュリティの共同責任
      • クラウド事業者は、利用者支援のため情報セキュリティ監査に必要な情報提供・機能提供をすること
      • ↑の共通的な基準を表したものが「ISO/IEC27017」
    • ISO27001, ISO27002 のクラウド
  • CSC自身による情報セキュリティマネジメント

  • CSCのための情報セキュリティ機能および情報の提供(サービスマネジメント)
  • CSPの責任範囲における情報セキュリティマネジメント
  • 共同責任

    • CSC(Cloud Service Customer)
      • 1.2. が責任範囲
    • CSP(Cloud Service Provider)
      • 2.3. が責任範囲
  • 監査

    • 文書化した証拠を提出
  • クラウド情報セキュリティ監査の特徴

    1. クラウドのリスク(see WebSite)
    2. プロセスの透明化
    3. 監査調書の雛形を提供
  • クラウド利用者がやるべきこと

    • リスクに応じた利用と対応
    • 監査報告の内容や認証制度の適応状況を踏まえた事業者の信頼性の評価
    • 利用者が負うべき責任を果たすこと
      • クラウド提供者との責任分界の確認と対応
      • クラウド利用に対するガバナンスの確立
      • 情報セキュリティの運用

10:45-11:25 基調講演:サイバーセキュリティ研究の最前線 井上 大介

(国立研究開発法人 情報通信研究機構 サイバーセキュリティ研究室 室長)

今日の資料 https://goo.gl/9JR2eU

  • NICTERとそのスピンオフ技術たち

    • グローバル観測(ダークネット)
      • NICTER
        • ダークネット from-to の通信を観測
      • DAEDALUS
    • ローカル観測(ライブネット)
  • 最近はIoT機器からの通信が多い 23port telnet

    • 日本国内では監視カメラが多い
  • クラウドからクラウドへの攻撃

  • AWSNIRVANA

    • AWSのセキュリティ機能は多々ある
      • Amazon Inspector(脆弱性自動検査)
      • AWS CloudTrail(エンドポイント監視)
      • VPC Flow Logs(通信監視)
      • Amazon Cloud Watch(アラート通知)

11:25-12:05 基調講演:日本のサイバーセキュリティ政策と政府等の対策の動向 三角 育夫

(内閣サイバーセキュリティセンター(NISC) 副センター長 内閣審議官)

新たな「サイバーセキュリティ戦略」について - サイバー空間 - 5th Domain of War - 「無限の価値を生むフロンティア」である人工空間 - 経済社会の活動基盤 - 土台・基盤の大半は「民間」によるもの

  • 政府統一基準の改定
    • 事案発生に備えた対処体勢(CSIRT)、対処・連絡手順などの整備にかかる規定の効果
    • 不正プログラム感染の発生を前提とする情報システムの防御策の強化
    • 情報及び情報システムへの不正アクセスの防止等を目的とする対策の見直し・強化
    • 新たなIT製品・サービスの普及に伴う対策事項の明確化

12:05-13:05 ランチ休憩

13:05-13:50 AWS グローバルコンプライアンス最新情報 Sara Duffer

(Sr. Manager, AWS Risk, Amazon Web Services, Inc.)

  • 規制対象業務とセキュリティ・アシュアランスにおけるグローバルの状況
  • グローバルな規制、および重要業務における原則
  • 各種リソース・情報

FinTech企業の100%はクラウドAWS)を利用

様々な形態の金融機関がクラウド利用を広げている
各国の法令規制に則ったかたちで導入を検討する必要がある

  • ガバナンスプラン
  • データセキュリティ
  • BCP
  • リバーシビリティプラン

  • グローバルにおける規制の原則的な共通要求事項

    • Location of Data
      • データの配置場所は「利用者」が決める
    • Vendor Oversite
    • Data Protection / Securty Addressed
  • AWS Quick Start Program : PCI DSS

    • Standard Architecture for AWS PCI-DSS
  • Securty Operation

    • SOC2 で対応
    • 日本におけるAWSの災害対策(Web)
  • gamedays

    • Activation and Notification
    • Validation
    • Engagement
    • Assessment
    • Recovery
    • Reconsititution
  • Data Protection / Securty Addressed

    • 3 lines defense
      • Operations
        • ビジネス環境のセキュアな構築
        • ex.) Cloud Formation
      • Supervisory
        • セキュリティ対策の有効性を確認
        • ex.) Inspector
      • Evaluation
        • 内部監査などの独立性を有する評価
        • ex.) CloudTrail
  • セキュリティに関する運用の自動化 : Automation

    • Design
    • Package
    • Constrain
    • Deploy
  • 情報リソース

13:50-14:35 セキュリティ・ソリューション・アーキテクチャ : データの完全性に関する考慮事項 Chris Whalley

(Life Science Risk Prgm Manager, AWS Security, Amazon Web Services Inc.)

Data Integrity in the AWS

  1. AWSの概要
  2. データ・インテグリティの概要
  3. トップ10 データ・インテグリティ・コントロール

  4. データの定義

    • Diffenent types of data require different types of data integrity controls.
  5. トップ10 データ・インテグリティ・コントロール

    1. リスクベースのソフトウェア設計、テスト
    2. データアクセスへの制限
    3. 監査証跡へのアクセスの制限
    4. データの同時記録
    5. 文書フォームのコントロール
    6. 定期的な監査証跡、データ、メタ・データのレビュー
    7. 監査報告の完全な保持
    8. 規制対象となるソフトウェア・アプリケーションの検証
    9. 経営上層部のデータ・ガバナンスの実装についての責任
    10. 経営上層部エラー・レポートについての前向きな検討の促進

14:35-14:55 休憩

14:55-15:40 金融機関のグローバルな規制対応情報

梅谷 晃宏 (アマゾン データ サービス ジャパン株式会社 セキュリティ アシュアランス本部 本部長 日本・アジア太平洋地域担当)

AWS FISC対応への情報は公開中 →MAS TRMガイドラインに関する情報

今泉 智(トレンドマイクロ株式会社 事業戦略推進部 業種営業推進グループ マネージャー)

シンガポールでCLOUDSECというクラウドセキュリティイベントを実施

MAS:Monetary Authority of Singapore シンガポールの金融当局規制

日本もシンガポールも、概ね同時期に、FISCやサイバーセキュリティが整備された

MAS TRM/FISCガイドライン 足立 道拡(NRIセキュアテクノロジーズ株式会社 ストラテジーコンサルティング部 部長)

世界的な災害脅威のうち、サイバー攻撃も災害に位置づけてられており、 先進国においては最重要項目にあげられていることも。

シンガポールは「働きやすい国」No.1(関税が低い)ため ビジネス・情報が集まる国なので、同様にサイバーセキュリティについて 国家レベルで関心が高い。

MAS TRMガイドライン9章 おもにサイバー攻撃対応の要求事項が記載されている。

15:40-16:25 製薬医療機器業界のクラウド対応(仮題)

梅谷 晃宏

(アマゾン データ サービス ジャパン株式会社 セキュリティ アシュアランス本部 本部長 日本・アジア太平洋地域担当)

AWSにおけるGxPクラウド GxPコンプライアンスのリソース

尾崎 孝一(東洋ビジネスエンジニアリング株式会社 ソリューション事業本部 関西ソリューション部 部長)

CSV(Computer Service Validation)

  • クラウド環境のバリデーション手法
    • ITインフラのクオリフィケーション+アプリのバリデーション
  • バリデーション対象システムのクラウド環境採用の課題
  • クラウド環境採用の促進に向けて

鴻池 明 (フィラーシステムズ株式会社代表取締役

16:25-16:30 クロージング

梅谷 晃宏 (アマゾン データサービス ジャパン株式会社 セキュリティ アシュアランス本部 本部長 日本・アジア太平洋地域担当)RR

Jenkinsオジサンからの卒業その4(werckerを試してみた)

Wercker

wercker.com

git push からのビルドとデプロイを自動化することを目的に作られたサービス。ビルドの後続処理をPipelineで繋いでいけるのが醍醐味らしい。

使い方

  • アカウントの作成は、独自アカウント作成 or GitHub連携で可能
  • 自動ビルドさせたいリポジトリを選択する
  • 対象リポジトリの設定を幾つかやる
    • deploy key の自動登録を任せるのが一番楽
  • 対象リポジトリのルートに wercker.yml を配置する
    • ここで気付いたけど、werckerがデフォルトで yml サンプル定義を提供しているのは、 GoLang, NodeJS, Python, Ruby ということが判明し、もしやJavaには対応していないんじゃないのorz として企画に幕を下ろしかけた
      • けども、いやまてよ。Dockerコンテナでコマンド実行するだけの汎用的な仕組みなら java 用のコンテナを指定しつつ Drone.io と同様に gradlew とかでビルドできるのではないか
  • ということで、Java ビルドがしたければ、ボックスの指定を box: java:8 とかにするべし
    • Gradleを使いたい場合は、gradlew 一式をリポジトリにcommitすること推奨
      • ビルドコマンドはこんな感じ
steps:
  - script:
      name: gradlew
      code: |
        ./gradlew
  - script:
      name: gradle build and test
      code: |
        ./gradlew check

色々と試行錯誤をしましたが、結果的にはちゃんとビルドできました☆

自動ビルドのトリガー

  • Push
    • default branch 以外のPushもブランチを区別してビルド結果を残してくれる
  • GitHub上のPRとも連携してくれる
    • ビルドがとおったPR(commit)か?が確認できて便利

ビルド結果

  • build badge のURLを提供
    • 過去数回分のビルド結果がRed/Greenの色分けで見れて、コードの安定度の目安にできるかも
  • ビルド成果物(Artifacts)の保存
    • できるのかもしれないけど、方法わからず
  • Mail通知
  • Slack通知

初めはヒントが少なくて戸惑いましたが、UIもイケてるし、多重度2まではFreeで使えるし、リポジトリ&開発者は無制限な模様。なかなか良い感じなのではないかと。

その他

  • 内部的にはコンテナ上でビルドが走る
    • 各ステップの詳細ログが見れる
  • UIはいい感じに今風
  • そういえば、醍醐味である自動デプロイや、Pipeline設定は試していなかった...

SampleでWerckerビルドを設定してみたリポジトリはコチラ
https://github.com/shionit/sample-wercker

Jenkinsオジサンからの卒業その3(Drone.ioを試してみた)

Drone.io

Continuous Integration · drone.io

GitHub以外のVCSホスティングサイトとの連携もでき、OSSなのでオンプレ環境でも利用可能。細かい機能面は今後に期待、か。以下は、OSS版ではなく https://drone.io/ で試したもの。

使い方

  • アカウントの作成は、GitHub連携・BitBucket連携・Google連携で可能
  • 自動ビルドさせたいリポジトリを選択する
    • 標準で対応しているビルド構成でよければ、これだけでビルド実行できる
    • 対応していないビルド構成の場合は、ビルド用のコマンドを drone.io の Settings ページで入力する必要がある
  • Java デフォルトで対応しているビルドスクリプトは Ant, Maven
    • Gradleを使いたい場合は、gradlew を推奨とのこと
      • gradlew をリポジトリにcommitしておく必要あり
      • ビルドコマンドはこんな感じ
chmod +x gradlew
./gradlew [task]
  • リポジトリ内にビルド設定を定義できない??
    • .drone.yml を置いたのに、読んでくれない?OSS版だけの機能なのか??
      • だとしたら非常に残念
      • 2016/07/28追記 OSS版では .drone.yml を読み込んでくれました

自動ビルドのトリガー

  • Push
    • default branch 以外のPushもビルド
  • GitHub上のPRと連携してくれない
    • ビルドがとおったPR(commit)か?は確認できない

PRと連携できていないのは残念。

ビルド結果

  • build badge のURLを提供
    • build badge 表示はlatest(最後に実行したビルド)のみ
  • ビルド成果物(Artifacts)の保存
    • マスタービルドで生成されるJar/Warを指定しておくと、Downloadが可能
  • Mail通知
  • ビルド後のデプロイタスクも設定可能

単純なビルドの成否を出力・通知するだけのTravisCIとの大きな違いとして、Artifactsの保存やデプロイタスクがある。branchごとではなく、とにかく最後にビルドした結果が残るという仕様が、少し残念なところ。

その他

  • 内部的にはコンテナ上でビルドが走る
    • 各ステップの詳細ログが見れる
  • UIは良く言えばシンプル、なんか物足りなくも感じる...

SampleでDrone.ioビルドを設定してみたリポジトリはコチラ
https://github.com/shionit/sample-droneio

Jenkinsオジサンからの卒業その2(CircleCIを試してみた)

Circle CI

circleci.com

GitHubとの親和性は高く、手軽に使えていい感じ。

使い方

  • Circle CI にGitHubアカウントでログイン
  • 自動ビルドさせたいGitHubリポジトリを選択する
    • これだけでビルド実行できる
  • 対象のリポジトリcircle.yml を置かなくてもビルドは可能のようだが、今回試したJavaプロジェクト(TravisCIで試したものと中身は同一)では置かないとビルドが通らなかった

自動ビルドのトリガー

  • Push
    • default branch 以外のPushもビルド
  • Pull Request
    • 追加Pushで再ビルド

Travis CIと遜色ない印象。

ビルド結果

  • build badge のURLを提供
  • ビルド成果物(Artifacts)の保存
    • マスタービルドで生成されるJar/Warの他に、単体テストレポートや静的解析ツール実行結果も残しておけるので、閲覧が可能
  • Mail通知
  • Slack通知
  • ビルド後のデプロイタスクも設定可能

単純なビルドの成否を出力・通知するだけのTravisCIとの大きな違いとして、Artifactsの保存やデプロイタスクがある。

その他

  • 内部的にはコンテナ(デフォルトではUbuntu)上でビルドが走る
    • ビルドの各ステップの処理時間が確認できる
    • 各ステップの詳細ログが見れる
  • ビルド用コンテナにsshしてビルド失敗原因の調査や細かな環境設定が可能
  • テスト実行の並列度など細かな設定が可能
    • 複数コンテナで並行実行させるには有償プランにする必要あり
  • build スクリプトは自動検出
    • TravisCIと同様

SampleでCircleCIビルドを設定してみたリポジトリはコチラ
https://github.com/shionit/sample-circleci

Jenkinsオジサンからの卒業その1(TravisCIを試してみた)

Travis CI

Travis CI - Test and Deploy Your Code with Confidence

GitHubとの親和性は高く、手軽に使えていい感じ。

使い方

自動ビルドのトリガー

  • Push
    • default branch 以外のPushもビルド
  • Pull Request
    • 追加Pushで再ビルド

ビルド結果

  • build badge のURLを提供
  • Mail通知
  • Slack通知
  • ビルドがSuccessかFailか?の結果を出すシンプルな出力
    • Test結果のレポート表示はできない
    • ビルド成果物(artifacts)の保存もできない

その他

SampleでTravisCIビルドを設定してみたリポジトリはコチラ
https://github.com/shionit/chronos