fc2ブログ

makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

「Developers Summit 2016 - Hack the Real - 」に参加しました　- Part2 -

2016/2/18 ～ 2/19 「Developers Summit 2016 - Hack the Real - 」に参加してきました。

公式
http://event.shoeisha.jp/devsumi/20160218/

デブサミ2016、講演関連資料まとめ
http://codezine.jp/article/detail/9255

先日、Part1として聴講メモを一部書きました。


Part2として引き続き、聴講したセッションのメモを自分の復習のため書いていきます。

【18-A-1】　Yahoo! JAPANが考える、テクノロジーとITエンジニアの未来


http://event.shoeisha.jp/devsumi/20160218/session/980/

Yahoo! JAPANが考えるテクノロジーとITエンジニアの未来　#devsumi from Yahoo!デベロッパーネットワーク

インフラの進化

  • ＶＭは10kでオペレータが限界になった。
  • ⇒ OpenStackを導入して80k VMへ到達した。

プログラミング言語

  • プログラミング言語の選定基準は３つの観点で。
    • １．メンテンナンス、学習コストの最小化
    • ２．オープンソースとの親和性
    • ３．過去のソフトウェア資産の活用

Webサーバ
  • Webサーバは安定性とパフォーマンスのために独自のパッチを当ててカスタマイズしている。
  • 先頭にyを付けて、Apache ⇒ yApache、Node.js ⇒ yNode.js と呼んでいる。

HTTP Cache
  • WebサーバからCSSとかを配信するとコストがかかるので、自前でCDNを持っている
  • AkamaiなどのCDNサービスは使わない。
  • 大量のリクエストがWebサーバに行くことを防ぐために、中間にエッジ層を挟んでいる。

ヤフーテクノロジースタック
  • ここが強い、というより、Yahooを作るのに全部をYahoo Japanでやっている。
  • それは、システムがダウンした時の責任を自分たちが負えるようにするため。

利用する技術を議論して決める
  • 重要なのは、利用する技術をトップダウンで決めないこと。議論して決める。
  • GitHub Enterpriseにyj-tech-standardというリポジトリを作り、意見がある人はプルリクエストで議論ネタを上げるようにしている。

ヤフーは４月で20歳になる
  • Web業界で20年生き残るのはあまり無い。
  • 20年前の1996年は、ヤフーのトップページはカテゴリしかなかった。
  • Filo CGIというサービスエンジンを使っていたが、Yahoo創業者の独自開発だった。
  • Filo Serverも自分で組み立てていた時代。

目の前にあるユーザの課題をとにかく解決し続けた。例： ログイン認証
  • 1998年当時は、ログイン認証はどうやったらいいかわからなかった。
  • 2007年はBBAuth (Browser-Based Authentication) というブラウザベースの認証APIを提供していた。
  • 2008年はCBA (Client-Based Authentication) で、アプリに保存したIDとパスワードを認証サーバに送る方式だった。今では考えられない。。。
  • ID乱立の問題が出始めた。未来を考えずに作ると大体こうなる、という悪い例。
  • どうせ標準仕様を作るのなら、流行らせないと辛い。
  • 認証と認可を同時にできる標準仕様としてOpenID Connectを作った。
  • いつのまにか、国内ソーシャルログインのシェアNo.1になっていた。
  • つまり、Yahooのログイン＝日本のログインなんだ。ヤフーのログインを作るということは、日本のログインを作るということ。
  • これに気づいていなかった。気づいていたら、もっと違うアプローチが取れたかもしれない。

ログイン　→　ビッグデータ
  • ログインする → 質の高いデータがたくさん集まる → ビッグデータ
  • この繋がりにも気づけなかった。気付ければもっと違うアプローチが出来たかもしれない。

変わらないものはない
  • 今日のベストは明日のベストではない。
  • もっと重要なことは、課題が分かってから対応するのは遅いということ。
  • 未来はどうあるべきか、を考えて取り組むことが重要だと痛感した。

未来の課題の予測と解決に必要なもの
  • 技術力とマインド。
  • テクノロジー（技術力）は陳腐化するが、マインドは陳腐化せず、普遍的なもの。
  • マインド醸成のため、会社で大決起集会をやった。

世界Top10を目指す
  • なぜマインドが大事なのかというと、世界Top10を目指そうと思っているから。
  • なぜ世界Top10を目指すのかということ、技術には国境が無いから。
  • GoogleやAmazonと勝負して勝たないといけないので、必要条件になっている。

未来への準備
  • １．広告課金技術の特許　・・・　特許は数年単位がかりで取り組んでいる。
  • ２．オープンイノベーション　・・・　強い企業と最強タッグを組みましょう。
  • ３．Open Compute Project　・・・　IoTで機器からたくさんログが来るが、数年先、インフラが間に合うかが一番の課題。
  • 　→　ハードウェアにもOSSの考え方を。オープン仕様に基づいたハードウェアを海外拠点に入れている。
  • ４．ビッグデータ関連の研究開発　・・・　YahooはWeb企業だけじゃなく研究開発企業なんだ
  • ５．オープンソースへの貢献　・・・　OSSコミュニティにContributeの形で貢献していく。

【18-C-3】　JavaScript.trend(spec) /* 最新言語仕様を軸とした JavaScript の最先端解説 */


http://event.shoeisha.jp/devsumi/20160218/session/998/

Java script.trend(spec) from dynamis .


JavaScript、ECMAScriptの誕生
  • Selfを取り込んでJavaScriptはプロトタイプ指向になった。
  • 設計がマズかったね、と後悔する部分もあった。
  • 最初はMozillaが１人でJavaScriptを頑張っていた。

ECMAScriptの成長
  • JavaScriptが足りない部分を補うためCofeeScriptやTypeScriptが登場してきて、それらのノウハウがJavaScriptに還元されていった。
  • JavaScriptの言語仕様を作り始めて３年くらい経って最低限のものが揃ったので、次は、それを立派な言語にしていこう、となった。
  • そのあと、折り合うところだけやりましょう、ということで標準化へ向かった。
  • ECMAScript2015(6th)で抜本的な修正が入った。Class、Module、・・・
  • 今後は6th、7th・・・ではなく、インクリメンタルに少しづつ年次改定していく。
  • ECMAScriptの仕様を知らないと、良さの半分も活かせてないことになる。
  • ECMAScript 2016で新機能が２つ入る。Array.prototype.includesとexponentiation operator
  • ECMAScript 2017はSIMD.jsとAsync Functionsの２つが注目。前者はマルチメディア演算。後者は非同期処理を綺麗に書けるC#から持ってきた機能。

Babelトランスパイラの利用
  • トランスパイラとは、最新の言語仕様で書いたコードを、IEでも動作するように変換してくれるツールのこと。使うことでバグが入りにくくなる。
  • トランスパイラによる変換は当たり前になってる。
  • HTTP Connectionを如何に減らすかが課題で、HTTP2になったらCSSを１つに纏めるより、個別に分けたほうがキャッシュが効いて良い。
  • → JavaScriptもそうなっていくのでは。いつでもモジュールに分けて設計し、タスクランナーで変換して合体するとか。
  • → タスクランナーを使いましょう。

ES6
  • これからはES6で書きましょう。
  • Template Literals（テンプレートリテラル）を使うことでコードが書きやすくなる。
  • Destructuring（分割代入）を使うと、代入の左辺も階層構造が取れる。JSONの階層構造の代入も一撃で行ける。
  • 今まではブロックスコープを作る機能が無かったので、何もしない即時関数を作って、そのスコープを利用していた。
  • →　ES6でBlockscope（ブロックスコープ）の機能が追加された。
  • Readable Asyncで非同期処理がすごく書きやすくなった。


【18-E-5】　リアクティブ・アーキテクチャ～大規模サービスにおける必要性と課題


http://event.shoeisha.jp/devsumi/20160218/session/1017/

リアクティブ・アーキテクチャ ～大規模サービスにおける必要性と課題〜 #devsumi from Yuta Okamoto


なぜ分散システムか？
  • 例えば組織200人で開発、とかは無理なので、分ける。開発組織をスケールする。

マイクロサービスアーキテクチャ
  • マイクロサービスアーキテクチャは昔からあった。
  • 2011年に書かれたAmazonに対する記事がとても良いので、読むと良い。　http://anond.hatelabo.jp/20111018190933

コンウェイの法則
  • システムのアーキテクチャは、その組織のコミュニケーション構造のコピーとなる、という経験的法則。

マイクロサービスの方法論
  • サービス間はRESTや単純なMQで繋ぐ。SOAのESBのような重厚なものでは繋がない。
  • サービス同士の依存関係を減らし、独立化してコミュニケーションを減らす。

リアクティブ宣言

様々なリアクティブ
  • 世間のリアクティブは、Reactive Programmingを指すことが多い。これはReactive Architectureとは違う。

リアクティブシステムの性質
  • ４つの特製がある。即応性、弾力性、レジリエンス、メッセージ駆動。
  • ユーザへ素早く一貫性を持たせてサービスを届ける。その形態が「弾力性」と「レジリエンス」の２つ。
  • 三層アーキテクチャのシステムのやり方とは似ても似つかない。
  • ビジネスロジックが小分けになって、非同期で結びつく。

リアクティブなコンポーネント
  • 他のコンポーネントから非同期メッセージが到着したときだけ反応する。
  • この、「だけ」という点が重要。リアクティブ＝受け身。
  • コンポーネントは、いつ動くかというのをシステム任せにできる。

レジリエンス
  • リアクティブ宣言では、レジリエンスを「対障害性」と訳しているが、ちょっと違う。
  • 障害で倒れてもいいけど、すぐ回復する、という特性がある。

Onion Layered State Management
  • 上の２つのコア（Error Kernel）は壊れちゃいけないけど、それより下のオブジェクトは壊れても上の２つがなんとかしてくれる。　

マイクロサービスとの比較
  • マイクロサービスは同期呼出がデフォルトで非同期呼出も許されるが、リアクティブは非同期呼出のみ。

データフローの決壊
  • Publisherが非同期でメッセージを大量に送りまくっても、受け取る側（Subscriver）の処理が追いついているなら問題ない。
  • 受け取る側（Subscriber）の処理能力がしょぼいと、メッセージバッファが溢れる。

Back-Pressure
  • 受け取る側（Subscriber）が、送る側（Publisher）に、いくつ送ってください、と言う。
  • 送る側は、リクエストされた分だけメッセージを送るので安全。

Reactive Streams in JDK 9
  • JDKにReactive Streamが入る。抽象的な概念がもうつ使えるところまで来ている。

分散オブジェクト設計の法則
  • 第一法則：　オブジェクトを分散させるな　by Martin Fawler　「分散って大変なんだぞ」

分散プログラミングのつらみ
  • １．プログラミングが大変
  • ２．整合性の確保が大変

ログ指向アーキテクチャ
  • メッセージの順番は、ログを書いたところで確定する。


ひとまず自分の復習のため、スライドや当日メモを見ながら書きました。
残りのセッションはPart3以降に続きます。。。
関連記事

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバック URL
http://makopi23.blog.fc2.com/tb.php/206-c561b1e3
この記事にトラックバックする(FC2ブログユーザー)

-->