GitHub Japan Constellation Tokyo 2018 〜Day 2 Developers in Business〜
2018/06/13 (水)
9:00 - 17:00 JST
公式サイト：https://githubsatellite.com/
参加申し込み：https://peatix.com/event/366939
ライブストリーミング：https://githubsatellite.com/live-stream/
Twitter HashTag： #GitHubSatelliteTokyo
体調崩したり、ドタバタしていてUPが遅くなってしまい、鮮度も何もあったもんじゃないですが、記録残しておきますー
基調講演：GitHub Enterpriseプロダクトビジョン
公家 尊裕 (GitHub) ジェイソン・ワーナー (GitHub)
（冒頭はDay1と同じ話）
Tokyo向けに作ったロゴ。富士山、東京タワー、桜。桜はブランチを表現。
GitHub上の成長率
- 中国・インドと並んで、日本はTop Growing Countryのひとつ
日本国内IoT市場
- 2017年：6.2兆円
- 電力はスマートメーターへの切り替えが行われている
- 電力自由化後に電気会社を切り替えると、そのタイミングで機器交換される
- エネルギーの利用状況から、生活上の利用傾向分析・推測ができる
- 集めたデータをどう解析して、どんなサービスに還元していくか、がビジネスの勝利につながる
- 2022年：12.5兆円（IDCの予測）
- 2017-2022：14.9% CAGR
日本国内コグニティブ／AIシステム市場
- 2017年：274億円
- 2022年：2947億円（IDC予想）
- 2017-2022：60.7% CAGR
- ソフトウェアの勝負
- 欧米では開発者の奪い合い
- 自動的にエンジニアの給料も上がる（お約束はしませんが）笑
- 欧米では開発者の奪い合い
2030年 IT人材不足
- 79万人（経済産業省）
- 毎年、４〜５万人が不足する計算
- これから若者を育て続けても、間に合う気がしない
- 頑張る？（残業する？）→ 事実上無理
- ツールを使って効率的に開発を進める
- 世界中の色んなエンジニアを集めて、グローバルなチームを作る
- 上記、2. 3. のMix
- GitHubは、4.のアプローチを取っている
GitHub Enterprise
- 日本の企業ユーザの95%が、Enterpriseを利用
- （ここで弊社ロゴ・キター！！）
ジェイソン・ワーナー
Every company is an innovation company
- not software company
- 単なるソフトウェア会社ではイノベーションは起こせない
- 優秀なソフトウェア会社とは？
- 難しい課題のバランスが取れる会社
- セキュリティ
- スケール
- アダプション
- インテグレーション
GitHubの責任
- データ侵害を防ぐ
- コンプライアンスに準拠しつつイノベーションを促進させる
- オープンソースコミュニティへのサポート
- Tokenの漏えい等は自動的に防げたらどうだろうか？
- こういった機能でGitHubは協力できる
- Tokenの漏えい等は自動的に防げたらどうだろうか？
コード革命 → クラウド2.0革命
- Pull Request
- ネットワークエフェクト
- GitHubは統合の支援、ワークフローの管理も支援できる
GitHubがお手伝いできること
- テクノロジーを組織の中でデプロイしやすくする
- 最高の人材を集める
ウェイン・ジン
これから我々がやってくことの紹介
- 4つの投資エリア
- プラットフォーム
- データ
- いかにセキュリティを確保するか
- エコシステム
- いかに拡張していくか
- 開発者
- デベロッパーをなるべく生産性の高い状態にする
プラットフォーム
データ
エコシステム
- GitHubはバージョンコントロールシステムだと思われていた
- コミュニケーション／コラボレーションのツールへと拡大していった
- 今は、マーケットプレイスがあり、サードパーティーの必要なフィーチャーを得ることができる
- アイデア
- コード
- ビルド
- デプロイ
開発者
- GitHubは開発者のためのサービスである
- 開発者の生産性を最大限にする
所感
出だし基調講演はDay1と同じ内容なのかとゲンナリしかけたが、エンタープライズ向けのビジョンや機能の表明により、日本国内は特にGHE比率が高いこともあり、より一層力を入れていくことが感じられた。
ゲスト基調講演：DMM.comのGitHub EnterpriseとCircleCI の活用方法
唐沢 陽介 (株式会社DMM.comラボ)
少ない人員でどうやって生産性を確保しているか？を紹介する。
GHEの構築から運用まで関わっている
- CircleCIの導入・サポートも
- CircleCI1.0を2.0への移行支援
今日話すこと
- （表題）のこと
- GHE導入して1年経って思うこと
GHEの活用状況
- 40くらいの提供サービスのうち、比較的新し目のサービスでGHEの採用が進んでいる
- ほかは、AtlassianのBitbucket（クラウド版）を使っている
- なぜミックス？
- 環境改善チームでBitbucketを試験運用していたら、どんどん現場が相乗りしてきた
- みんな本当はGitHubを使いたかった
- 本気でGHEを導入する検討を始めた
- 4つのサービスが稼働中
- GHE
- CircleCI
- ZenHub Enterprise
- SideCIオンプレミス
社内でおすすめしている利用パターン
- Gitのブランチモデル
- 基本は自由だが、相談が来たらシンプルな２つを紹介する
- Git Flow（簡易版）
- feature / develop / master だけ
- GitHub Flow
- master ブランチへのマージは検証環境へデプロイ
- Tagを打つと、本番環境へデプロイ
- CircleCIのうまい使い方
- ビルド＋インスペクション＋デプロイを実施している
- 素早いフィードバックを得るために
- Docker Executorをつかう
- Cacheを使う
- ダウンロードしたファイルはキャッシュする
- ビルドに必要なライブラリをダウンロードするが、毎回ダウンロードではなく、次回以降は使い回す
save_cache:とrestore_cache:
- Worlflowを使う
- 自動テストと静的解析を並列化する
- テストは全部やるが、静的解析は一部（別条件）など
- 自動テストと静的解析を並列化する
- Machine Executorは非推奨としている
- オンプレ版だと非推奨としている
- ビルドのたびに裏でEC2インスタンスが立ち上がる
- 2分以上必ず待たされる、遅い
- 起動数の変更にサービスの再起動が必要で運用が難しい
- CircleCIですばやくフィードバックループを回す
- 速度を意識していないとすぐに遅くなる
- 少しの工夫で高速化できる
- 困ったらGHEで検索する
jobs ruby filename:config.ymlで言語ごとのビルドジョブ定義を社内で探してベストプラクティスを横展開できる
- ドキュメントはGitHub Pagesで
- GHE → CircleCIビルド → GitHub Pages
- ZenHub Enterpriseで進捗の可視化
- GitHubの中だけで開発業務が回るようになった
導入して1年
- 新規サービスではGHEとCircleCIの採用が進む
- 利用者はサーバやユーザ管理が不要で、すぐにCIを始められる
- .circleci/config.yml でアプリケーションの動作要件が分かる
- 既存プロジェクトも移行できるところから移行
- 悩んでいること
- 対策として個人的にやっていること
- 良いリポジトリを見つけたらスターを付ける
- 少しずつ、この文化が広がってくれれば良い
所感
DockerコンテナベースのCIツールとの連携など、弊社と似たステージにいる認識。すべての既存プロダクトを移行できていなかったり、諸々の課題についても似てより、参考にできるところは取り入れていきたい、リザーブドインスタンスとか。。。
ゲスト基調講演/パネルディスカッション：ソフトウェア開発の変遷と、これから
モデレーター 及川 卓也 (フリーランス技術アドバイザー) 大倉 香織 (株式会社サイバーエージェント) 小林 篤 (株式会社ディー・エヌ・エー) 松野 徳大 (LINE株式会社)
GitHubの10年を踏まえ、今後の10年をうらなう
軸となるテーマ
- 一番進化を感じる技術は？
- 事前に登場や進化を予測していなかった技術は？
- 逆に期待はずれだった技術は？
及川：Git前とGit後で社内の開発は変わったか？ 小林：開発者間のコミュニケーションが多くなった 松野：手元で1回コミットしておけるので、途中の作業を保存しやすくなった。途中からカフェに移動して作業したり、とか。メンバーも分散して作業できるのが嬉しい。 及川：コミュニケーションでいうと、SlackとGitHubをペアで使っているところが多い？ 大倉：GitHubを先に入れたが、Slackに更新を通知させたりして現在は活用している 小林：Chatbotとして「安藤さん」を作って利用している（記事あり）
及川：言語のトレンドとして何が増えて何が減った？ 松野：perlとJavaで開発していた会社が一緒になったのだが、最近はJavaが主流。PythonとJavascriptも増えてきた。Swift/Kotlinもスマホ向けに利用している。 小林：Rubyやgo-lang。最近だとJavaが増えてきている。 及川：最近、Javaが増えた、というのは面白いがなぜ？ 小林：人が増えてくるにつれて、新しい人も理解しやすい意味で、型があったり、キッチリした言語にしようか、という話が出てきた。 大倉：ここ最近はgoが多いが、従来はJavaが多かった。
及川：言語採用はどうしている？ 松野：若い人はperlをあまり知らないので、採用が難しくなる。最近は採用しやすい言語を使うよう考えている 小林：最近はgo-langが流行ってきているので、採用にも効いていると感じられる 大倉：同じく最近はgo中心にプロダクトを構築していて、世の中的にも増えてきている感がある
及川：10年前と今では何が違う？ 小林：インフラでクラウドの進化が大きい、今ではクラウドを選定しないことがほとんど無いくらいになっている 及川：インフラエンジニアの仕事が変わってきている。
及川：10年前に機械学習を意識していたか？それを機械学習またはAIと呼んでいたか？ 松野：10年前は今ほどパフォーマンス広告よりも純広告が多かった。今はどういうユーザが広告をクリックするか？などの分析はやっている。 小林：10年前はAIとか言われていなかった。ルールベースでアルゴリズムを処理する、ベイジアンフィルタをかます、などは昔からあった。それが進化したのが今だと思っている。 及川：Googleの検索だって今となればAIと言われるようなものだが、当時はそういう「ラベル付け」がされなかった。
及川：NVIDIAがこんなに大きくなるとは思っていなかった。 小林：GPUの用途が格段に広がった。
及川：皆様の企業はどういう風に変化しているか？ 大倉：グループごとのCTOが事業に最適な技術を選定するようになってきている。 小林：事業部ごとにCTOを置くようになってきている 松野：だれが開発をリードして、誰が決定してくのか？を明文化するようになってきている 及川：テックリードやCTOという肩書きや役割が明示されるよう、組織の文化が変わってきている。
及川：今、注目する技術？ 小林：自動車産業にむけてのオートモーティブ事業に、ITS（インテリジェントトランスポートシステム）への適用が重要。Uberとかを導入するにあたり、日本は世界に比べて遅れをとっている。土木や都市設計にも関わってくる。次世代の環境を作るためには、日本のITSを底上げしていく必要がある。 及川：日本は要素技術は強いが、応用をする際に、横の連携がまだ足りない感がありますね。 大倉：RPAの導入をしていきたいが、APIが公開されていない（？）など厳しい状況にあるが、できるようになっていきたいと思う。（？） 及川：人間の動きをシミュレートしたり、そういったもので代替されるが、なんとかテックといったものが縦の機能で閉じていて、横の連携をするためにAPIを公開して連携可能にすることで、ユーザーフレンドリーなものが作れるようになっていくのかな、と。 松野：非常に沢山のデータが集まってくる。どういったものを集めて利用していくのか、が重要。気軽に大きなHadoopクラスタを構築できるようになってきたので、その後の扱い方が重要。 及川：データを集めることはできたとして、そのデータをどう扱うのか？が重要だが、データに対するリテラシーはどうやって育てられているか？ 松野：データサイエンティストを積極採用したりしつつ、Tableauサーバなど気軽にBIで分析できる基盤を整えたりしている
①例えば、プログラマとして、どこまでプログラムを書かないといけないのか？ 及川：インフラはほとんどスクリプト一発で実現できることが増えてきている。GitHubのChrisも、将来はコーディングがなくなっていく世界が来ると言っていた。 松野：どういう要件が必要で、どこがどういうコンポーネントで、といった要件を整理するところは少なくとも人がやるんだと思っている。徐々に、ブロックを繋げるだけで実現できる世界が広がってきているのを感じる。 及川：書き方は簡単になってきているが、やろうとしていることが難しくなってきているので、結果的に書く量は変わっていないようにも思える。 小林：自動車産業がなぜこんなに自動化するか？というと、人間が操縦したりすると事故が起きるから。つまり、人間がコードを書くとバグが生まれる、ということの解決としてプログラミングも自動化されていくのではないかと思っている。
小林：RoRなど簡単なものが増えてきた弊害として、裏側の本質的に行われていることを理解していない人が増えてきているのは、どこかで問題につながりうるのではないか。
及川：マインクラフトの話があったが、ビジュアルプログラミングはどれくらい出てきているか？ 大倉：子供向けにスクラッチをやらせてみているが、まだ難しいようだ。子供向けのRubyの本のほうが分かりやすいかと考えている。 及川：ビジュアルプログラミングは、バージョン管理と人とのコラボ（ソーシャルコーディング）が難しく感じる。
及川：将来に向けてインフラエンジニアはどうあるべきか？ 大倉：抽象化されたことで自動化やプログラムで解決されるものが増えてきたが、コードを書くのか、より深い要素技術を理解して身につけるのか、どっちかかと思う。
及川：チェスの大会や、自動運転車の世界でもあるように、機械の横に人間が座って、協力して結論を出していく組み合わせがベストな解決につながる、という世界がしばらくは続くと思う。
②ソフトウェアにより制御可能な世界 SDxやxxx as a service その進化はソフトウェア開発やインフラへどう影響を与えるか （途中、メモれず・・・） 及川：Software eating the world. とも言われるように、ソフトウェアが世界を変える、という流れがしばらく続くかと。
③チーム開発の将来は？VRやARが与える影響は？リモートワークの今後 小林：隣りに座っている人ともSlackで会話する、ということも出てきている。だが直接会って話さないと伝わらない空気感や感覚があるし、初めて会う人がずっとChatというのも抵抗が残るので、対面コミュニケーションはなくならないと思う。 松野：グローバルな拠点でのやり取りはChat(LINE)だったりビデオ会議でやることがある。ビデオ会議でも通訳を通しても通信が不安定だったり、情報が落ちることがある、対面で通訳を通したときの方がまだ安心感がある。今後はVRで徐々に解決されていくのかもしれない。 及川：音声が不安定だと、途切れるのを恐れて、短いフレーズで話す傾向がでてしまい、短い文言での発言だと「怒ってるのかな？」みたいに本来のニュアンスで伝わらないことがある。
最後にひとこと 松野：今後も色んな技術によって、いろいろと便利になっていく、それらに触れられるのが、作る側としても楽しみ。 小林：作り方も高度化している。企画して設計して作って、ではなくユーザ体験とか考慮するようになっている。それらを柔軟に対応できるようになっていきたい。 大倉：今日のディスカッションを踏まえてオートメーション化について今後もディスカッションができると嬉しい。
所感
golang普通に使っている企業が増えてきたなー。生の及川さん初めて見たー（ミーハー心）
GitHubと共に学生を育てる方法
古橋 大地 (青山学院大学)
@mapconcierge
2017年度の大学1年生
文系の学生ですら、ここまではやってるんだな、という話
いつも学生に見せる樹状図
- 生物の進化
- 様々な形で生き残るもの、生き残らないもの
- どういう情報が継承に値するのか？
- どうやって教育していくべきか
教育の中でGitHubを利用している
- GitHubの地図を作っている？
- GeoJSON
- 点情報、緯度＋軽度
- 拡張子は
.geojson
- ベクタデータ全般が扱える
- Github上でレンダリングされる
- 背景地図はGoogleマップではない
- 私達が作っている「OpenStreetMap」
- https://openstreetmap.jp/
- GeoJSON
どんなことを教えているか？
- 課題：XYZタイル画像のデータ仕様を図化しなさい。
- 技術者としてではなく、技術者と一緒に活動できるようになりなさい
キャンパス内でドローンを操作してみる体験
- ドローンレース
- どういう映像がドローンを通して見えるか
- ドローン操作がうまくなる
最先端の技術をどうやって社会実装できるか、を考えられる学生を育成
- OpenStreetMap
- 一億総伊能化
- GitHubに様々な地図情報を提供
Wikipediaを参考にしたモデル
- Free Wiki ...（？）
オープン（＝商用利用可能）
オープンストリートマップ
- 5.0M規模のボランティアの力
- 海外の仲間との情報共有
- 公開にすることで、学生に適度なプレッシャーになる
- 外部の人からコメントが来たりする
- ウェブサイトはGitHub Pages
Gitの仕組みは、Git-it で経験。
- https://github.com/jlord/git-it-electron
- 文系の学生もコマンドを使わせる
- GitHubが使えないことで、そのコミュニティに入れないのは大きな損失である
- 学生に説明するプレゼン資料はSpeakerDeckで公開
- GitHubと空間情報
- GitHubの履歴は就職活動の履歴書にもなる
- 就職活動前から（1年生から）育てていく必要がある
- Issueでのやりとりも、PRもすべてがエビデンスになる
最近は、GitHub Projectでタスク管理
外（社会）と中（大学）をつなぐ架け橋がGitHub
- Publish or Die! （公開するか、さもなければ死を！）
所感
文理系に関係なく、学生にITリテラシーを植え付けようとするその志と、オープンな地図ソリューションで社会貢献しようという情熱が半端なかった。これくらい徹底してGitHub中心に生活させるようにしないと、リテラシーの底上げは実現できないよな、と痛感。
SlerがGitHub Enterpriseを使ったら
原口 猛 (株式会社セゾン情報システムズ)
所属グループ「モダン開発推進」とは？
- 既存のプロジェクトの進め方にプラスアルファをし、いいねを一緒に増やしていく
GHE導入編（SIerでもGHEが使いたい）
- 背景
- いざ導入
GHE運用編（え？運用は私一人ですか？）
- 2年間運用してトラブル０件
- 運用で必要となるのは、定期的なアップグレードのみ
- 運用工数はごくわずか
導入効果
- デイリーコミット（を推奨）
まとめ
- GHEはただのツールではなくプラットフォーム
- 文化を変えるためのプラットフォーム、豊富なプラクティス
- 導入ではなく定着がゴール
運用事例
- 事例１．ペアプロ・モブプロによるシングルブランチ運用
- PRベースじゃなくてFaceToFaceでレビュー
- ブランチはmasterブランチのみ
- 事例２．開発以外での利用例（ポータルサイト）
- GitHub Pages
- 静的コンテンツを簡単に公開
- GitHub Pages
マクニカネットワークス 根本さん
GitHub Enterprise の国内一次代理店
- 導入事例および支援サービスのご紹介
- GHE および CircleCI オンプレ版 の導入支援
所感
GitHub Pages 使っているところが多いなー
弊社でも有効活用しないとなー・・・
GitHub Marketplaceと、開発生産性を向上させる幾つかのSaaSのご紹介
角 幸一郎 (SideCI株式会社)
@sumyapp
コードレビュー支援サービスSideCIのFounder,CEO
背景
- 書籍「クラウド誕生」の出版2009年から9年が経過
- オンプレミスなソフトウェアやソフトウェアのない世界が残っている
- ソフトウェアはお金で買える、開発リソースはお金で買えない
- 開発者は仕事を効率化するために、SaaSやソフトウェアを遠慮なく使える世の中になって欲しい
発表後にやって欲しいこと
- GitHub Marketplaceですぐに使える便利なサービスを知って、使ってみて欲しい
SideCIで使っているサービスは、数多くある
- 10数名規模の会社だが、無数のサービス利用によって生産性を最大化している
GitHub Marketplaceとは？
Marketplaceサービスの紹介
- Coveralls | Code quality
- https://coveralls.io/
- テストカバレッジがいろいろな方法で非常に見やすい
- 行ごと
- ファイルごと
- 時系列
- SideCI | Code review
- https://sider.review/ja
- RuboCopやCheckstyleなどの解析機を使って、コードレビューを支援
- GitHub PullRequestと連動
- コードを解析、問題点をサジェスト
- 静的解析ツールは必ずしも正しい指摘をするわけではない
- 誤検知をCloseする機能あり
- プロジェクト固有のルールも検査できる
- 購入パイプラインによって並列実行も可能
- 今日から sider にサービス名変更
- Dependabot | Dependency management
- https://dependabot.com/
- Dependencyの自動アップデート
- PRを自動で生成
- アップデートでCIが落ちるか？が分かる
- PRを自動で生成
- Rollbar | Monitoring
- https://rollbar.com/
- 例外検知サービス（めちゃ便利）
- スタックトレースが見られる
- ユーザの環境情報も（ブラウザなど）
- 例外のトレンド把握や検索が可能。
- ZenHub | Project management
- https://www.zenhub.com/
- GitHub Issues をボードで表示
- GitHub Projects よりも高機能
- ベロシティ計測、リリース可能日予測
便利なサービスがたくさんある
- 開発生産性を飛躍的に引き上げてくれる
- 簡単に導入できる
- 人の時間は有限。スケールアウトもできない
- SaaSなら人の時間を節約できる
所感
今までは、ほとんど自前でゴリゴリと周辺サービス連携をしてきてしまっているので、マーケットプレイスを有効活用して、楽に（お金で解決して）生産性と品質を確保する選択肢を増やしていかないとな。
GitHubを軸とした開発プロセスのリプレイス
大平 哲也 (株式会社スタートトゥデイテクノロジーズ)
テーマ
- いかに開発者の負担を減らして、楽しく開発できるようにするか
- 主に「自動化」について話します
開発環境を取り巻く状況
- 開発体制
- 基本・内製
- 100名強のエンジニアでサービスの開発と運用。
- 本社と密に連携
- 慢性的な人手不足
- ZOZOTOWNシステムリプレイスプロジェクト
- おおまかな方向性
GitHub導入以前
- 他社のインストール型Git Repositoryを利用
- 様々な問い合わせが発生し、十分に対応しきれない
- サーバが落ちる、ログイン不可、重い
- 社内での運用は人手不足
- インストール版のGit repoだと、各種SaaS/PaaSと連携するために自作○○が必要になる
GitHub機能比較 by スタートトゥデイ（GBHの価格は $21 で、GHEと同じ）
GitHub Business Hosted
GitHubエコシステム
- Wercker（CIツール）
- 自動化
- テスト
- いわゆるUnitTestを実施
- DSLの内容もチェック
- Terraform/Ansible
- コード品質の評価
- push時に品質を自動でチェック
- Code Coverage
- Code Smell
- Duplications
- PRレビューの補助
- SonarCloud（SonarQubeのクラウド版）
- 様々なコードメトリクスを収集
- コード自動生成
- 仕様は一箇所で表現したい
- 仕様を書いたら、そのとおりに成果物ができて欲しい
- Swagger / OpenAPI
- YAML/JSON で仕様を定義
- 定義どおりにコードを自動生成
- Swagger to Mock API
- Swagger to API Code Template
- SpringBootの例（Controller Interface）
- Swagger to API Client Implementation
- Swagger to Spec Document
- API仕様をドキュメント化＋動作確認できる
- Swagger to Postman
- APIテストツールPostman用の設定ファイルを自動生成
- https://qiita.com/moaikids/items/1e05ef2595504689fe3e
- Swagger to JMeter
- 性能テストの元となる設定ファイルも自動生成
- https://qiita.com/moaikids/items/2f0029ea246c5f6818d9
- 成果物のパッケージ
- デプロイ
- ...追いつけず
- テスト
総括
- GitHub Business Hostedを採用することで運用負荷を減らす
- 様々なエコシステムを利用できたので、開発者の生産性を向上
- GitHubをフル活用して開発者が楽しく開発できる環境にしていきたい
所感
k8sを使っている事例を当たり前に紹介されることが増えている気がして、やばい出遅れている感（！）
企業開発に役立つGitHubの最新機能
池田 尚史 (GitHub)
@ikeike443
プリセールスのエンジニア
- ROI計算の支援とかしてる
GitHubとは
- The software development platform
- ソフトウェア時代の主役は開発者であり、それを支援する
- 色んなバリエーションのプロダクトごとに様々な開発手法がある
- あらゆる開発手法を受け止められる開発プラットフォームである
- 10年間に書かれたコード量：500TB
- 昨年1年間のコミット数：15億
- マージされたプルリクエストの数：1億
- 85%のプルリクエストは、実はPrivate（主に企業による利用）
企業利用の選択肢
- GitHub.com Business Hosted
- GitHub Enterprise
- コードベースは同じ
- エンドユーザー視点で同じ機能を提供
- GitHubBH
- GitHub社が運用、マルチテナント、米国
- GHE
- 社内にインストール、御社のポリシーで
代表的な機能
- GitHub Flow（機能というかプロセス）
- GitHubが提唱しているベーシックな開発フロー
- Git Code Repository
- Pull Request
- Issues
- Projects
- 巨大なエコシステム
- 各種ツール、エディタ、チャットツール、CIツールとの連携
企業利用に役立つ機能
- Platform
- Administration
- Org/Team
- Nested Teams
- 権限グループのネスト
- Approval flows
- Teamへのメンバー追加
- Organizationへのサービス追加
- Team Discussions
- チーム単位でディスカッションができる機能
- Organization Permissions
- メンバーの初期権限
- リポジトリの可視性
- Forkの可否
- 2要素認証の使用有無
- Protected Branches
- 特定のブランチを保護し、マージ条件を設定できる
- Code Ownerによる承認を必須に
- CIやテストのパスを必須に
- 特定のチームのみマージ可能
- Nested Teams
- Developer
- Projectsの改善
- 自動化カンバンボード
- Issueのステータスとカンバンの位置移動を連動
- 進捗のビジュアライズ化
- 権限管理
- テンプレート
- キーボードショートカット
- 自動化カンバンボード
- 複数のIssueテンプレート
- ナビゲーションの追加
- 特定言語について、Jumpと編集が楽に
- コメント編集履歴
- Projectsの改善
まとめ
- 企業内開発に役立つ機能
- Issues/Projects/Pull Requests
- Organization/Teamによる権限管理
- 運用管理に役立つ様々な機能
- 今後も進化していきます
- GitHub Changelog で変更点は確認できる
所感
Security Alert / Checks API は待望。
GitHub Enterpriseアドミンパネルディスカッション
モデレーター テレル・ブルーマ (GitHub) 伊集院 圭介 (ブラザー工業株式会社) 井内 聡 (フリュー株式会社) サマーズ ハリス 和弘 (楽天株式会社)
テレル・ブルーマさん @domofactor
１．GitHub導入時点の話 て：導入した理由は？ さ：インフラを導入していく仕組みのリポジトリを管理していくにあたり、GitHubを使えなかったのでGHEを使った て：大規模な企業だが、簡単に導入できたのか？ さ：導入には苦労はなかった 伊：システム的な問題としてプロプライエタリなVCSはWindowsでしか使えず、Mac/Linuxでは別のものを使っていた。ソーシャルコーディングが開発者から求められていた中で、GitHubEnterpriseを使っている他社の事例を見て憧れを抱いていた。そういうCoolなツールを使いたい、という思いが強かった。 井：レビューを強化しようという流れの中で、SVN＋Redmineで行っていたが、GitHubのPullRequestの方が効率的だったので、導入した。.comの利用にはハードルがあったので、GHEを採用した。
て：導入で苦労したことは？ 井：SVNからGitへの履歴を含めた移行はすぐにできたが、SVNの外部参照を多用しており、代替の機能がgitにはなかったので苦労した。最終的にはgit-submoduleを使って実現したが、ディレクトリ構成の変更などを伴い苦労した。また、git自体の理解と習得に苦労した。 伊：プロプライエタリなVCSからの移行だったので、事例がない情報がないので苦労した。ツールを使っていたが、特定条件のリポジトリは必ず失敗する、などが起きて職人芸的にクリアせざるを得なかった。gitに理解のないエンジニアに移行を促す作業は、なかなか骨が折れた。今は古いVCSはシャットダウンできている。 さ：最初は特定プロジェクト向けにgitを導入したが、どんどん周囲のプロジェクトから手が挙がって利用者が増えた。当初はライセンスの購入が追いつかなかった。また、よりオープンに公開する文化にシフトするなかで、秘匿化しなければいけないトークンなどまでオープンにしてしまうことを防止したり、そういったポリシーを定めるのに苦労した。
２．いま時点の話 て：GHE導入して、何が変わりましたか？ 伊：一言で言うと文化が変わった。自分たちで調べてブランチ戦略を考えたり、勝手にPullRequestでコードレビューを始めたり、そういった変化が自然に起きた。 さ：各プロジェクトが自分たちで作っている製品を管理していたが、今は、チームを横断してPRを投げたりするような文化ができ始めている。良い変化だと思う。 井：様々なツールを見ていたのがGitHubに一本化されて効率があがった。またPRの時点で仕様や要求の共有ができるようになった。
て：GHEを管理していて困ったことは？ 伊：ソフトウェア的に問題が起きたことはない。Org/Teamの管理が自分自身でしかできない点が課題。 井：サーバ側でのトラブルはない。gitの勉強コストが困ることがある。git操作での事故がチラホラある。レビューを通すことが必須になったため、本流に入るまでの時間が長くなった部分もある。 さ：弊社はプライベートネットワークとパブリックネットワークが分かれており、それらのインターフェースを毎度設定する必要があり苦労している。今は解決している。
て：管理者からみてGHEのいいところは？ 井：安定しているサービスである。サポートが日本語で対応してくれるのも助かる。 さ：安定性はすごくありがたい。他に使っている他社製品はDockerベースのものが多いが、落ちたりバグったりする。管理者用のドキュメントも分かりやすくていい
て：ユーザの反応はどうですか？ 伊：良好。早く作業ができていい、という声を聞く。GHE内のすべてのコードを検索できるため、社内の特殊なノウハウを探して参考にしやすいのが嬉しい。 さ：使い出すと戻りたくない、という声が多い。 井：リポジトリをまたいだ検索はありがたい。使うべきではない関数の横断検索などは効率的にできた。
（オーディエンスから質問：福留さん）サーバの運用周りについて、手がかからないという話があったが、何か管理面で自動化の工夫をしている点があれば教えて欲しい。 さ：GHEはモニタリングでGraffanaが統合されているが、独自のモニタリングツールと統合したい場合に、モニタリングのAPIを使って情報を吸い出している。
て：これからGHEを導入したい人へのアドバイスは？ 井：PRは開発者にとって大きな変化なので、1つの最善の選択だと思う。 伊：競合製品と比べるのは良いと思うが、結局はGHEに辿り着くと思う。サポートのレスが早い。情報文献も多い。
会場風景
タイムテーブルとフロアマップ（今日はPegasusエリアを使わず）
このクッションを持ち帰りたかった
GitHub Japan Constellation Tokyo 2018 〜Day 1 Community〜 #GitHubSatelliteTokyo
2018/06/12 (火)
11:00 - 20:00 JST
公式サイト：https://githubsatellite.com/
参加申し込み：https://peatix.com/event/366890
ライブストリーミング：https://githubsatellite.com/live-stream/
Twitter HashTag： #GitHubSatelliteTokyo
基調講演：ソフトウェア開発の未来
公家 尊裕 (GitHub) ジェイソン・ワーナー (GitHub)
GitHub サービス開始が2008年、今年でちょうど10年。
GitHubという会社は、コラボレーションとリモートオフィスという考えを大事にしている。全世界に社員がいるが、長い間オフィスはアメリカ１つだった。
2015年、GitHubのアメリカ以外の最初のオフィスができた。場所は、Tokyo。
ソフトウェア開発の未来に貢献していきたい。
今、開発現場で起きていることは？（ジェイソン・ワーナー）
開発者
- 皆様が書いているコードが、今、地球上で大きな原動力となってる。
- ソフトウェア開発者になるのに、今ほどいい環境・状況はない。
より複雑化する開発環境
- 数年前の時点で、平均的な自動車は、1億Stepのコードで動いている。
- 2017年、平均的な開発者は1000以上のクラウドサービスから選定をしている
- 進化は止まらない、追いついていくのは容易なことではない
コミュニティは知識の集合体
私達が最初に作ったもの。
- 信頼性の高いバージョンコントロールシステム、Web経由でアクセス可能なもの。
作ったシステムは、次第にコミュニティを構築していった。
- そしてオープンソースソフトウェアが活発に作られるようになった。
人やデータ、ツール、すべてが繋がっていくことで成長・進化していく。
開発環境の複雑化は止まらない
- アイデア、コード、ビルド、デプロイ
- 無数の意思決定がプロダクト作成までの道のりでは必要。
過去、今日、未来
- 人々が積み上げた試行錯誤を段階的に未来につなげていけるのが、GitHub
ツール・サービスには、あまりにも多くの選択肢が用意されている
- これらをすべて評価してマスターしていくのは不可能
これらの乱立するワークフローを解決するのが、Pull Requestだった。
複雑化する開発環境
- 単純化するプラットフォーム、合理化したソリューションが必要
- ガチガチに固められたソリューション？
より良い開発環境構築のために
開発者感コラボレーションの促進
開発者に必要なのは、より多くコードを書く時間と、ユーザのことを考える時間
新しいテクノロジーは次々と出てくる
ソフトウェア開発が将来どういうかたちになっていくか、は誰もわからない
- どのようになろうと、複雑性を排除してシンプルに開発できる環境を整えることに注力したい
様々な問題を解決するのは開発者の皆様です。
- GitHubはそれを支援します。
日本マイクロソフト株式会社CTO 榊原 彰 氏
設計図共有サイトのファンの皆様、こんにちは（会場爆
すべてがコンピュータ・ソフトウェア産業になっていく。
- それを作り、支えていくのは開発者の皆様です。
マイクロソフトは変わってきた、あなたのお父さんの世代のマイクロソフトとは違います。
- 言っても信じてもらえない人もいる
- 言葉ではなく、行動で示していきます。
GitHubの独立性を保って、すべての開発者が今までどおりGitHubの機能を安心して使っていけるようにする。
- LinkedIn やマインクラフトでも独立性を維持してきた
- これが、我々の今のミッションです。
- これからの我々の行動を見ていただきたい。
empower all developer
- 我々がやりたいこと。
- すべての開発者とともに、未来を作っていきたい。
パネルディスカッション：Rubyが生まれた頃、そしてこれからのRuby
アーロン・パターソン (GitHub) まつもと ゆきひろ (Rubyアソシエーション)
GitHubのソフトウェアエンジニア、アーロン・パターソン
（互いに旧知の仲らしく、2人でのセルフィー撮影に始まり、終始和やかなムードで対談）
あ：GitHubはRubyで書いてあるので、まつもとさんありがとう。
あ：Rubyはいつ生まれた？ ま：1993年です。 あ：どうやって生まれた？ ま：バブル経済が崩壊して景気が悪かった、ソフトウェア会社の社内ツールを開発するチームに在籍していた。そういうツールは売上がたたない。景気が悪いのにそんなことをやってられない、プロジェクトが解散した。社内にはツールのユーザが既にいたので、面倒を見るために残されたエンジニアが2人だけ残った、そのうちの一人。何年もかかって作ったツールを2人ではサポートを回せない。自分で作ったもの以外も多数あったので、基本的にトラブルシュートは「再起動してください」で終わらせていた（笑。上司は兼任で忙しかったが、自分たちには時間があった。誰も管理していない状態、そんな中で作ったのがRuby。 ま：会社で作ったが、著作権の考え方に厳しい時代じゃなかったのと、上司が許してくれたので、退職時に外へ持っていけた。上司が許可してくれなかったら今のRubyはなかった。
ま：GitHubに公開されているRuby/Rubyは、公式のミラーであり、実際はSVNで開発が行われている。 ま：なぜGitHubに移行しないのか？をよく聞かれる。RailsもGitHub。PythonのセントラルリポジトリもGitHub。 ま：RedmineでIssueを管理していて、RedmineとSVNを連携させる作り込みを相当しているので、使い続けるという状態。あと、GitHubサービス自体はOSSではないので、一部のコアなエンジニアが完全オープンなサービスにしかアカウントを作りたがらない、というのもある。そういう人々を離脱させたくない。
あ：まつもとさんがGitHubを初めて使ったのはいつ？ ま：Ruby本体で使えなかったので、アカウントは作ったが、ほとんど使っていなかった。自分用のメールリーダーを自作している、OSSにしていないのでユーザは自分しかいない。それを修正するためだけにPRを3回だけやった。
ま：mRubyは、最近の普通の開発がしたかったので、最初からGitHubにホストしている。やっぱり楽でいい。リポジトリなどを自分で管理するのはよくない、と改めて思った。
あ：Ruby開発のコミュニケーションの問題はあるのか？ ま：Rubyのコアコミッターは100名くらいいる。日本人が半分くらいだが、スーパーアクティブな人が日本人なので、日本人がコミッターであるイメージが強い。 ま：Rubyの開発は、オープンソースだけどクローズドだ、と海外の人で言われた。日本人が日本語でいつの間にか方向を決めてやっている。それ以降、Redmmineにすべて内容をダンプして、公式言語も英語にして、オープンになるよう心がけている。議事録も英語で書いているので、日本語がわからないとRubyができない、という世界にはならないようにしている。
あ：Rubyの未来について ま：頑張って進歩を続けている。RubyやRoRは「ハイプ曲線」を過ぎて、Rubyは死んだ、と言われている（笑 ま：Goなどの静的な型がある言語が持ち上げられてきたので、様々な理由で毎年死んだと言われ続けている（笑 ま：大きなサイトでRubyが使われているのは事実で、そういったサイトをもっと支援したい、と考えている。性能問題が出たときに独自カスタマイズしたRubyを作っている人々が昔はいたが、大体が残っていないと思うし、本来Rubyユーザが汗をかくべきところではないと思っている。 あ：アウトオブバウンズGCの説明。Webサイト利用者にGCによるレスポンス遅延影響を最小化する手法。GitHubで利用することで劇的にUXが改善した。 ま：そういう感じでコアチームの努力によって、Rubyユーザが独自にRubyをパッチしなくてもいいようにするのが責任だと思っている。
あ：プログラミング言語を作るのが好きなまつもとさんの、プログラミング言語のストリームについて教えてください。 ま：言語をデザインする人が、言語をデザインするときにどういう事を考えて設計しているのか、ということが分かるような連載を書いている。そこで作り始めたのがストリーム。まず200行くらいの文法イメージを書いてGitHubにバックアップ目的でアップロードした。特に隠す必要もないと思いパブリックリポジトリにしていたら、次の日に、「まつもとがプログラミング言語を作っている！」というのが見つかって、バズって1000スターくらい一気に行った。。。全然作業途中のものなのに、PRは来るわ、言語のアイコンを作って投げつけられたり、色んなことが起こって、OSS時代の開発は全然違うな、と思った。フリーソフトウェアの時代とは違う。
あ：まつもとさんの開発環境について ま：普段使っているエディタはEmacs。コンパイラーはgcc。 あ：なんでRubyのソースコードの中で同じファイルの中にTabとSpaceが混在しているか？ ま：どっち派の人もコミッタにいるが、最後に触った人の修正した行が、その人の行はその人の流派になる。特に統一しようとしていない。 ま：昔はスペースよりもタブ派だった。データ数が少ないので。最近はスペース派になった。git blame が効かなくなるので、変換するためだけのコミットをしていない。
あ：私は自作キーボードを使っているが、どういうキーボードを使っているか？ ま：Thinkpadのキーボード、マイクロソフトのエルゴノミクスキーボードを使っている。最近はレッツスプリットというキーボードを使っている。タップキーボードを最近買ったが、まだ使いこなせていない。
余談：日本独自文化「笑う」の意味での「草（w）」の話と GitHubの「草（Contribution activity）」の話。（アーロン大爆笑）
所感
話を聞いている雰囲気から、Matzは細かいことを気にしすぎない包容力があるから、Rubyのコミッタを含むコミュニティを「いい感じにゆるく」まとめていけるんだなー
エンジニアにとって窮屈さを感じさせる環境を作らない、というのが非常に感じられる。 でも大事な部分はキッチリ真面目に説明責任を果たすし、Techリードはこうあるべきと感じた。
OpenSTFをオープンした結果
シモ・キンヌネン (Dragon Standard Inc.)
https://github.com/openstf/stf
Co-Founder
- OpenSTFとは？
- 2015年サイバーエージェントがオープンソースした社内プロジェクト
- ブラウザから多数のスマートフォン端末を操作して動作確認ができる
- Control and manage Android devices from your browser.
- 今日は、OpenSTGについては話さない、どのように成長したかを紹介します
- GitHub Starは
- 9345ついた
- 公開後、安心安定の成長
- Fork数、Issue対応数もどんどん増えてる
- PRの数、200弱あった
- 公開前は誰もPRしてくれないのでは、という不安があった
- 公開直後はJumpStartした（知名度が最初にドッと増えた）
- サイバーエージェントというブランドの後押し
- 話題性、日経新聞に載った
- ポイント
- 実際にニーズがあった
- 他のオープンソースのものがなかった
- なぜ成長が進んだか？
- ライセンス：Apache2.0なので、ほぼなんでもできる
- 自然な成長
- インド・中国・ロシアでは意外と人気
- クラウドが安定していない、または信用できない傾向のある国である
- 端末の種類が多い
- 定期的なアップデート
- インド・中国・ロシアでは意外と人気
- 辛くなったこと
- メールボックスの状態が、OpenSTFのメールだけで埋まっている…
- オープンソースのイメージが変わった
- 文化的な違い（サポートの辛さ）
- 他人の時間を大事にしない
- 困ったことがあったら自分で調べるより誰かに聞きたい
- ドキュメンテーションがあっても読まずに直接聞きたい
- （折角用意してある）Issue Template を消す
- 他人の時間を大事にしない
- 言葉の壁
- 何で困っているか、通じないことがある
- 問題を把握するのに非常に時間がかかる
- 詳しい説明がないから何回も同じ情報を聞く必要がある
- Issue Template が理解できない
- 技術の進歩
- 昔、私達しかできなかったことが、新しいAPIのおかげで比較的ラクに
- 他のソリューションもある
- ライセンス
- Apache2.0なので、ほぼなんでもできる
- 私達のものをそのままか、ロゴを変更するだけで売っている会社がある、残念
- 普通に嫌なこと
- 「○○機能ってまだ？」
- 「有料の他のツールでは、それができてるよ？」
- 「じゃ、ほかのものにするよ」
- すべて解決できるわけではない
- 役に立ったこと
- メンバーを増やす
- 昔は厳しかったが今は２〜３回目のPRでPushを許可する（権限を付与して正式なContributorに）
- 最初は怖いかもしれないがGitなのでかなり安定する
- （いざとなれば force push で履歴改変）
- Issue Template をできるだけ短くする
- 何が起きた・何をした・ログの有無
- 考えすぎて無駄に長くすると誰も入力してくれない
- スクロールすると読んでくれない
- もちろんCIを設定する
- （ビルドが落ちても直さない人がいるけど・・）
- Issue が来たら、すぐに対応にかかる時間を判断する
- 3分以下なら、すぐ返事してクローズする
- それ以上なら、あとにする
- CHANGELOG.md をちゃんと管理する
- 何がいつ変わったか簡単に分かるから無駄に聞かれない
- リリースノートでそのまま使える
- 無駄な約束をしない
- 「それ、いつかやるつもり」と言ったら無駄に期待されるので、興味・時間がなかったらハッキリ言おう
- ビジネスをやるつもりがなくてもサポートの値段ぐらいはちゃんと準備しよう
- 高めにすると面倒くさい要求が簡単に回避できる
- メンバーを増やす
- 良かったこと
- 普通より面白い仕事をチャレンジできた
- いいエンジニアと連携できると最高
- いろいろなイベントに招待された
- LA、ロシア、中国など
- 「タイに来てうちの経費で○○機能を作って」という依頼も
- いろいろな会社と連携できた
- 恐ろしいスケールのデバイスラボも見せてくれた
- 仕事にもなった
- たくさんの端末と遊ぶことができて楽しかった
所感
オープンソースプロダクトを扱う身の 生々しい苦労話とやりがいの話。
Matzのストリーム話との共通点は、オープンにすることで多くのフィードバックが生まれプロダクトの成長が加速した、という点かと。
Microservices in ABEJA Platform - 集約と分散のサービス設計
石川 尊教 (株式会社ABEJA)
我々がどのようにマイクロサービスを開発＆運用しているか？
- 3 Topics
- About us
- Technology
- Culture
About us
- Deep Learning のGoogleトレンド紹介
- 2012年付近から、急激に右肩上がり
- 2012年 ImageNet Challenge 2012
- インターネット上にある画像を分類・画像認識をするコンテスト
- 毎年開催されていたが、2012年にブレイクスルーが発生
- Deep Learningモデルが従来の統計的モデルを圧倒
- 認識エラー率は年々低下している
- Abejaも2012年創業
ニューラルネットワークの簡単な説明
- （「ゼロから作るDeep Learning」）
- Data collection
- Annotation
- Training
- Inference
- Re-Training
- に戻る
Abeja は創業6年
Technology
Microservicesとモノリシックサービスの連携
- 30を超えるリポジトリ
- 5つの開発言語
- サービス間は gRPC で通信
- なぜ10名程度の会社でマイクロサービス化を進めたか？
- Complexity（複雑性）
- スケーラビリティが求められる機能
- UI/UXが求められる機能が
- 並列実行のバックグラウンド機能
- Motivation（）
- 開発者は顧客にサービスを届けるのが使命
- 開発者は新しい技術を使いたい、使う機会を得たい
- Microserviceであれば、新しい技術の採用ハードルが低くできる
- No Rules
- 世の中で定められているレベルの最低限のルールを守っているだけで、社内の独自縛りはない
- Complexity（複雑性）
- ARMSの紹介
- モノリシックなGatewayサービスがバックエンドのマイクロサービスのドメインの管理しやすさを後押ししている
- 中央集権的に実現したい機能はここに実装する
Culture
Diversity
- 英語を公用言語としているが、日本語ベースのトレーニングも用意
- Self Starter
- 待ち、ではなく、能動的なキャッチアップと貢献を推奨
- LEAN & Flow
- Waffleをつかったカンバンで朝会を実施
- リモートオンライン会議はZoom
- LEAN開発
- 毎朝のミーティングでカンバンを見ながら同期
- 自分のスキルと興味に応じてタスクを
- 壁の一部がホワイトボードになっていて、すぐに会議が始められる
マイクロサービスアーキテクチャを採用して良かった点
- プラットフォームの構築に向いていた
- 複雑とはいえ、各サービスの役割が明確
- 今のフラットな組織に合っている
- メンバーが固定化されづらい
- 新規メンバーが参入しやすい
- 興味のある言語や分野から入っていける
各サービスをつなぐ中心になるもの、（ARMS）を用意することをオススメする。
GitHub LT大会 ~ 事件は現場で起きている!?
モデレーター 鈴木 順子 (GitHub) アーロン・パターソン (GitHub)
36名の応募者、7名が選ばれた。
GitHubでポータルサイト ドキュメントを運営して幸せになる話
NTT.com 岩瀬ヨシマサさん
https://www.slideshare.net/iwashi86/github-102233959
- GitHub Pages
- GitHub Pagesを使うモチベーション？
GitHub as an Authenticator
Wantedlyオオツボシンペイさん
- 情報共有
- 社員名簿
- 権限管理
- GitHub を使って法務コミュニケーションのスピードを2倍にした話
- 組織上のチームとGitHub上のTeamが対応
- 複数チームの兼務も表現できる
GitHub Teamをベースに認可
- HRのフローに乗るだけで良い
- JOINしたときにTeamに所属させるだけ
- 権限の外し忘れがない
- Orgから外せばすべての権限がrevokeできる
- 特定Teamに入っているとプロダクションへのSSHを許可
- Webhook Token Authentication on kubernetes で
- Teamごとに異なるk8sの操作を許可する
- HRのフローに乗るだけで良い
Summary
- 社員全員をGitHubに入れる
- 組織に合わせてTeamを作成
- Teamに準じて認可する仕組みを
Githubをどうやって初心者に教えるか
湊川あい @llminatoll
「マンガでわかるGit」の著者
http://webdesign-manga.com/git01/
https://www.amazon.co.jp/dp/4863542178
- 土日にブログで書いたGitに関する初心者エントリーがメディアに取り上げられて書籍化
- git教え方いろいろ
- 口頭
- ドキュメントを紹介する
- 聞かれるたびに手を止めて対応
- 「なんかおかしくなっちゃいましたー」
- Gitを教えるのは大変！
- なぜ？
- 初心者にとってGit用語は異国の言葉に聞こえる
- まずは用語を１つ１つ説明していく
- それでもなかなか覚えてもらえない
- ビジュアル化すると理解が早まる！
- 人の脳が見たものを理解するのにかかる →0.1秒
- 脳の50%は視覚関係に使われている
- 文章＋絵だと認識率が圧倒的に高い、という研究結果
- ＋漫画だと
- 時間軸
- 状況
- 登場人物の心理
- を表現できる（私が漫画という手法を選択している理由）
- 漫画でリポジトリを説明してみる
- フォークとクローンを説明してみる
- まとめ
- 学習コストが高いと言われるgit
- ビジュアル化されていれば短時間で理解できる
所感
そういえば、gitの社内説明で絵を何枚も書いたなぁ。
git説明に限らず、ビジュアル化は本当に大事。
GitHubを導入したいとき、どう説得するか
Yahoo! タナカマサユキ
- GitHub使っていて当たり前？
- 導入に向けｍ社内を説得するために戦っている人もいるはず
- 導入の壁いろいろ
- 重要な関係者がGitHubを理解できていない
- うまく説明できない
- GitHubってなに？を改めて考えてみる
- 機能がいろいろある
- Yahoo!のアプリ開発環境で考えてみる
- 「開発業務の起点」
- 開発の中心にいる
- 向き合っている課題
- 大事なのは、導入するサービスを理解し、腹落ちさせること
技術系同人誌執筆のすすめ
イマイケンタさん ＠Henteko07
- I love Developer Tools
- 同人誌は早く出版できて楽しい
- GitHubを使うと複数名の執筆でもうまく書ける
- 商業誌は出版に14ヶ月かかった（経験談）
- 同人誌だと2ヶ月程度でOK
- デメリ：リーチできる人が限られる
- 同人誌は自由（Freedom）
- なにものにも縛られない自由
- GitHub上でどうやって同人誌を作るか？
- ツライ点
- たくさんの画像を扱う書籍
- 画像管理がワケわからなくなる
- デザイン系の本であれば、GoogleDrive＋GoogleDocumentを使ってる
- たくさんの画像を扱う書籍
Mixiにおける技術競技イベント「git challenge」の裏側
Mixi：サトウリョウスケさん
- git challenge？
- 学生を対象としたgitを題材にした競技
- すでに8回開催、のべ168名参加
- どんな問題？
- チュートリアルをみんなで解く
Start OSS Contribution with you know
シバヤマリョウさん @serima
自分にできることからOSSコントリビュートしてみよう
- 初めてのコントリビュート
- CircleCIが1.0→2.0に（2018.8末で完全移行）
- OSSは継続的に開発されることが重要
- コントリビュートしたいな、と思うものがあれば気軽に参加すればいい
- 自分にできることを探す
- Issueを探す（Help wantedラベルは比較的難易度が低い？）
- ソーシャルコーディングを楽しみましょう♪
会場風景
入り口
GitHubグッズショップ
会場案内
GH Satellite : real-time contribution visualizer
Ask GitHubコーナー
CircleCIコーナー
講演会場ではテクノサウンドが流れる
戦利品
ORACLE が CIサービスの wercker を買収
携帯のメールアドレスに迷惑メールが来たので通報した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