Jenkinsオジサンからの卒業その4(werckerを試してみた) - Logic Delight
でお試し紹介した wercker がORACLEに買収された模様。
とはいえ、ORACLE Cloud内のSaaSとしてシナジーを効かせたい戦略ということで、wercker的にはログイン後の画面タイトルが「ORACLE＋wercker」と変わっただけで、モダンで素敵なUIやサイトの構成には特に変化は今のところない様子。
携帯のメールアドレスに迷惑メールが来たので通報した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は実験をすることを好む
- 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
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) クラウドセキュリティ推進協議会 事務局長）
政府統一基準におけるクラウド利用の基準
- 情報の格付けに従ったクラウドサービス利用の判断
- 外国法が利用されるリスクの評価
- サービス中断時・終了時の円滑な業務の移管
- ベンダーロックインをさせないルール・独自仕様の回避・利用者情報取得の自由
- 情報流通経路全般にわたったセキュリティ設計・セキュリティ要件
- 監査報告の内容や認証制度の適応状況を踏まえた事業者の信頼性の評価
監査にする記載（ガイドP118）
- ISO/IEC27017
- クラウド情報セキュリティ監査
ISO/IEC27017
CSC自身による情報セキュリティマネジメント
- CSCのための情報セキュリティ機能および情報の提供(サービスマネジメント)
- CSPの責任範囲における情報セキュリティマネジメント
共同責任
- CSC(Cloud Service Customer)
- 1.2. が責任範囲
- CSP(Cloud Service Provider)
- 2.3. が責任範囲
- CSC(Cloud Service Customer)
監査
- 文書化した証拠を提出
クラウド情報セキュリティ監査の特徴
- クラウドのリスク（see WebSite）
- プロセスの透明化
- 監査調書の雛形を提供
クラウド利用者がやるべきこと
10:45-11:25 基調講演：サイバーセキュリティ研究の最前線 井上 大介
（国立研究開発法人 情報通信研究機構 サイバーセキュリティ研究室 室長）
今日の資料 https://goo.gl/9JR2eU
NICTERとそのスピンオフ技術たち
最近はIoT機器からの通信が多い 23port telnet
- 日本国内では監視カメラが多い
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.）
- 規制対象業務とセキュリティ・アシュアランスにおけるグローバルの状況
- グローバルな規制、および重要業務における原則
- 各種リソース・情報
様々な形態の金融機関がクラウド利用を広げている
各国の法令規制に則ったかたちで導入を検討する必要がある
- ガバナンスプラン
- データセキュリティ
- BCP
リバーシビリティプラン
グローバルにおける規制の原則的な共通要求事項
- Location of Data
- データの配置場所は「利用者」が決める
- Vendor Oversite
- Data Protection / Securty Addressed
- Location of Data
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
- Operations
- 3 lines defense
セキュリティに関する運用の自動化 : 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
- AWSの概要
- データ・インテグリティの概要
トップ10 データ・インテグリティ・コントロール
データの定義
- Diffenent types of data require different types of data integrity controls.
トップ10 データ・インテグリティ・コントロール
14:35-14:55 休憩
14:55-15:40 金融機関のグローバルな規制対応情報
梅谷 晃宏 （アマゾン データ サービス ジャパン株式会社 セキュリティ アシュアランス本部 本部長 日本・アジア太平洋地域担当）
AWS FISC対応への情報は公開中 →MAS TRMガイドラインに関する情報
今泉 智（トレンドマイクロ株式会社 事業戦略推進部 業種営業推進グループ マネージャー）
シンガポールでCLOUDSECというクラウドセキュリティイベントを実施
MAS：Monetary Authority of Singapore シンガポールの金融当局規制
日本もシンガポールも、概ね同時期に、FISCやサイバーセキュリティが整備された
-
- Assosiation of Banks in Singapore が2016/8/2にリリース
- サイバーセキュリティの項目でクラウドについてガイドラインをリリース
- ABS 内のKey Control項目の抜粋
- 暗号化
- 変更及び特権アクセス管理
- アクセス管理と職務分掌
- セキュリティイベントモニタリングとインシデント管理
- ペネトレーションテストと脆弱性管理
- FISC と同様
侵入を前提とした対策を
- 防御だけでなく検知を強化
MAS TRM/FISCガイドライン 足立 道拡（NRIセキュアテクノロジーズ株式会社 ストラテジーコンサルティング部 部長）
世界的な災害脅威のうち、サイバー攻撃も災害に位置づけてられており、 先進国においては最重要項目にあげられていることも。
シンガポールは「働きやすい国」No.1（関税が低い）ため ビジネス・情報が集まる国なので、同様にサイバーセキュリティについて 国家レベルで関心が高い。
MAS TRMガイドライン９章 おもにサイバー攻撃対応の要求事項が記載されている。
15:40-16:25 製薬医療機器業界のクラウド対応(仮題）
梅谷 晃宏
（アマゾン データ サービス ジャパン株式会社 セキュリティ アシュアランス本部 本部長 日本・アジア太平洋地域担当）
AWSにおけるGxPクラウド GxPコンプライアンスのリソース
尾崎 孝一（東洋ビジネスエンジニアリング株式会社 ソリューション事業本部 関西ソリューション部 部長）
CSV（Computer Service Validation）
鴻池 明 （フィラーシステムズ株式会社代表取締役）
16:25-16:30 クロージング
梅谷 晃宏 （アマゾン データサービス ジャパン株式会社 セキュリティ アシュアランス本部 本部長 日本・アジア太平洋地域担当）RR
Jenkinsオジサンからの卒業その4(werckerを試してみた)
Wercker
git push からのビルドとデプロイを自動化することを目的に作られたサービス。ビルドの後続処理をPipelineで繋いでいけるのが醍醐味らしい。
使い方
- アカウントの作成は、独自アカウント作成 or GitHub連携で可能
- 自動ビルドさせたいリポジトリを選択する
- 対象リポジトリの設定を幾つかやる
- deploy key の自動登録を任せるのが一番楽
- 対象リポジトリのルートに
wercker.ymlを配置する - ということで、Java ビルドがしたければ、ボックスの指定を
box: java:8とかにするべし- Gradleを使いたい場合は、gradlew 一式をリポジトリにcommitすること推奨
- ビルドコマンドはこんな感じ
- 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通知
after-steps:として slack notification を指定- Slack側に incoming webhook を導入することで生成されるWebHookのURLを環境変数で設定してあげれば、通知が可能になる
初めはヒントが少なくて戸惑いましたが、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しておく必要あり
- ビルドコマンドはこんな感じ
- Gradleを使いたい場合は、gradlew を推奨とのこと
chmod +x gradlew ./gradlew [task]
- リポジトリ内にビルド設定を定義できない？？
自動ビルドのトリガー
- Push
- default branch 以外のPushもビルド
- GitHub上のPRと連携してくれない
- ビルドがとおったPR(commit)か？は確認できない
PRと連携できていないのは残念。
ビルド結果
- build badge のURLを提供
- build badge 表示は
latest（最後に実行したビルド）のみ
- build badge 表示は
- ビルド成果物(Artifacts)の保存
- マスタービルドで生成されるJar/Warを指定しておくと、Downloadが可能
- Mail通知
- ビルド後のデプロイタスクも設定可能
単純なビルドの成否を出力・通知するだけのTravisCIとの大きな違いとして、Artifactsの保存やデプロイタスクがある。branchごとではなく、とにかく最後にビルドした結果が残るという仕様が、少し残念なところ。
その他
- 内部的にはコンテナ上でビルドが走る
- 各ステップの詳細ログが見れる
- UIは良く言えばシンプル、なんか物足りなくも感じる...
SampleでDrone.ioビルドを設定してみたリポジトリはコチラ
https://github.com/shionit/sample-droneio
Jenkinsオジサンからの卒業その2(CircleCIを試してみた)
Circle CI
GitHubとの親和性は高く、手軽に使えていい感じ。
使い方
- Circle CI にGitHubアカウントでログイン
- 自動ビルドさせたいGitHubリポジトリを選択する
- これだけでビルド実行できる
- 対象のリポジトリに
circle.ymlを置かなくてもビルドは可能のようだが、今回試したJavaプロジェクト(TravisCIで試したものと中身は同一)では置かないとビルドが通らなかった- build.gradle ファイルからJDKのバージョンが読み取れなかった、と思われる
- Sample circle.yml file - CircleCI
自動ビルドのトリガー
- 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