次世代Webカンファレンス2019

SRE

メンバー

  • kani_b
  • deeeet
    • メルカリのマイクロサービスチーム
  • y_uuk1
    • マカレルやってた
    • はてなにいた
    • SRE本の内容は大体やってる

開発業務の割合

  • Googleのプラットフォートチームでやっていることを取り入れていこうとしている
  • ユーザーはメルカリのDevelopper
  • プラットフォームそのものもやっている
  • ユーザーサポートとプラットフォーム開発を5:5になるようにしている
  • これがトイルかどうかの分類は結構難しい
  • クオーター毎にレビューして次のクオーターの対策をマネージャーと考える
    • 例えば割合が多い業務は早めに依頼してもらうようにお願いする
  • タスクの割合の可視化方法
    • メルカリ:タスクに属性を付与して管理している
    • クックパッド:特にしてない。可視化に向けたモチベーション少ない。進捗確認の中で定性的に確認している。
    • はてな:スプリント毎にベロシティを計測し、ベロシティが落ちている場合は割り込みがあったねという分析をしている。本来のロードマップが進んでイルカどうかで判断している

オンコール・インシデント対応

  • クックパッド:オンコール対応は週次レビューを行い、重要な問題は再発防止する
  • はてな:毎日振り返って緊急対応する。当番は休日はあったが、平日はない。SREだけでなく全エンジニアがポストモーテムを書くことになっている。
  • メルカリ:モノリス時代はSREチームが担っていた。当番制で回していた。インシデントが起こったら関わった人たちがレポートを書くようにした。ポストモーテムは週一でSlack上で行った。

SLI/SLO

  • SLOはプロダクト開発者ではなく、プロダクトマネージャーやCTOが決めるべき
  • SLOをバイオレートする可能性があるものはアラート
  • モニタリングはデータドッグをメイン。ワーニングはSlack、アラートはPagerduty
  • オオカミ少年アラートが多いのをどうにかしたい
    • GoogleのSRE本の学びとしては、チーム内全員をアラート全員が見る
  • アラートのコード化を進めている

SREの今後

  • ばらけていくのが理想?
  • 皆がSREをやっていけば良い
  • マネージドサービスに任せる
  • 開発者全体に溶け込む
  • スリーナインのサービスは開発者だけでは厳しい。そこにSREが入るべき。
  • ML OpsについてはまだマネージドサービスがないのでそこではSREが必要になる
  • SREは科学に近づいている
    • 計測しやすくなる
    • 研究したり、方法論を決めやすい
    • 改善しやすい
  • 科学に近づいていくべきだと思う

SREの生存戦略

  • システムを理解したソフトウェアエンジニア
  • 科学的なアプローチにトライできる人
  • ソフトウェアかけるのは当たり前
  • マネージドにできないことにどれだけチャレンジできるか
  • SREは技術の話だけでなく組織の話だという文化が広まれば良い

用語

  • トイル
  • ポストモーテム
  • SLI
  • SLO

Security

メンバー

  • コキチーズ
    • セキュリティ診断
  • mala
    • LINEの人
    • Livedoorの残党
    • 障害対応
    • 全社横断の対応
    • 個人的にも活動
  • 柳橋さん
    • https://xss.moe/
    • メルカリ
    • 今はWebに限らずセキュリティ関連なんでも
  • 徳丸先生
    • セキュリティ会社やってる
    • コンサルの仕事、ブログ

最近のWeb脆弱性

  • CDN関連
  • Wordpress/EC Cube
    • ちゃんと使っていれば問題ない
    • お手軽に使えてしまうので素人が使っている
    • Wordpressプラグインを信頼するモデルだが、認証していないものもある
    • プラグイン入れるな
  • パッケージマネージャー関連
    • パケットに混入?
    • バージョンを固定していないことにより、勝手に入ってしまう
    • GitHub脆弱性チェックができる?
  • CVEの重要なもの読む
    • コードハイライトで重要度判断
    • 任意コード実行、TLS系は必ず情報追ってる
    • 著名なプロダクトのバグが流れてくるメーリングリストをフォローしておく

ブラウザの脆弱性についてどこまで意識すべきか

  • 基本はない
    • 何か問題あればアップデートされる
  • ブラウザ側で治すべき問題をWebサイトで対応するのはしたくない
  • 脆弱性のあるブラウザを使っているやつが悪い
  • つけないといけないヘッダーが増えてくるのは嫌
    • 脆弱性診断ツールだとアラートになる
    • 意義をわからずにつけるのは良くない
    • ヘッダーを一個つければよくしてほしい

cookie

CSPについて

  • Mercariで入れようとしているが面倒臭い
  • レベルの話?
  • fastlyが設定してくれれば良い
  • 問題があった時にレポートが来るようにしているが、量が多すぎる
  • とってはいけない情報までとってしまっているものもある
  • MicrosoftはXS FilterをやめてCSPに寄せる

プライバシー

  • GDPR関連でcookieセットにも同意を求める
  • 実装というか手続きの話
  • 同意の形骸化になっている
    • 本当に重要なものの合意ができない
  • 先ずは機械的に解釈できるようにするべき
    • 機械が読んでブラウザが判断できるようにする
  • 人間を相手にすると厄介
  • JSに同意をとる世界が来るかもしれない
    • あの裁判次第★
  • 既成事実を対象ユーザーが認知しているかは怪しい
  • Canvas Fingerprinting
    • 使うべきではない
  • アドテックのカンファレンスでセキュリティ/プライバシーのセッションがない
    • 知られていないのが大きい
    • JSONPで広告配信すると漏れる
      • ○○市に住んでいる人の特定
    • セキュリティ・プライバシーはプライスレス

難読化

  • 自分が使っているサイトが安全か知りたいのでやめてほしい
  • gzip圧縮だけで十分なはず
  • chromeの難読化解除だとメモリ負荷で固まるらしい
  • 難読化は食べ物の原産地を知らないことに近い

最後に

Microservices

メンバー

  • tagomoris
    • treasure data
  • fujiwara
    • カヤックのサーバーサイド/SRE
    • microservicesはやるしかない
  • tokuhirom
    • LINEで広告担当
    • 自然にやってればmicroservicesになる

分散トレーシング

  • トレーシングのライブラリ入れてる
    • AWSのトレーシー?
  • なんかあった時のログとしてとるには容量多すぎる
  • 送る条件を決めて送るっていう手もある
    • エラー
    • 時間がかかった
  • ログを串刺しに見る方法
    • IDで横断的に見るのは基本
    • LINEではログの収集基盤があり、串刺しで検索できるようになっている
      • zeppelingがあるので見れることはみれるはず?

障害対応

  • サービス毎に障害対応ポリシー作るのか
  • サービス出す前にあるコンポーネント落としてみて正常に動くかをチェックしている
  • カオスエンジニアリング
    • アプリケーションの作り状、リトライができてれば良い
    • LINEはカオスエンジニアリングに手をつけられていない
    • LINEでは新しく入った人の教育で試している
    • お客様に迷惑をかけなければ良いという考え方はある
    • NetFlixは月額課金だから問題ない?
    • 海外のビックプレイヤーがやっているからというで自分の分野考えずに導入するのは良くない
    • いつかやっておかないと障害起きた時に爆発する危険性がある
  • 特定のサービスが落ちた時にリトライしすぎて死ぬというのはありがち

canary deploy

  • やらないで爆発するよりやった方が良い
  • 常にはやらないが大きい変更の時はやる
  • サービス重要度や規模次第
  • 簡単にできるように作りこむのが大事(自動化必須)

サービスメッシュレイヤーのSW

  • consulを導入している
    • サーバー名等の登録
    • DNSキャッシュ
    • サーキッットブレーカー
  • どの段階で入れるべきか
    • 入れるのが当たり前になれば良い
    • アプリケーション作成側が楽になる
    • ある程度大きい会社であれば基盤部門が導入してくれれば良いはず

サーバーレス

  • firebaseの世界
    • 結局データ構造考える人がクライアントの人になるだけ

Microserviceの実装面

  • gRPC
    • クライアント言語によって対応状況の違いある
    • https化
      • マネージドであまり対応できていない
  • スキーマ固定が必須
    • 言語がバラバラになるとスキーマなしの通信は無理
  • MySQLを直接たたかずにgRPCで包むっていうやり方もある
    • failOver時の対応はgRPCの先
  • LINEはthriftが多い。一部はgRPC
  • JSON利用は減っている
    • パフォーマンス的に厳しい
  • 複数のプロトコルを1つのミドルウェアをしゃべるケースがある
  • Kafkaへの接続
    • クライアントが頑張っている
    • Perlクライアントライブラリは微妙なの多いので、Javaプロキシ繋いでいる

言語

  • JSONは大体の言語で良いのある
  • データ形式によっては言語毎に差異ある
  • Amazon/Googleがサポートしている言語を使うのが良い
  • Line:大体はJavaで解決するという立ち位置
  • kayak:Goが多い。昔のはPerl。型付の方が変なバグ起きない。数年前にGoに決めた。
  • 監視に対応しているかという観点も重要
  • Goの監視
    • GoのGC等のモニタリングするライブラリある
  • マイクロサービスは言語の変更はしやすい

人数が増えるとMicroserviceが当たり前

  • リポジトリで開発するのは大変
  • できるだけ分けるべき
  • ピザ2枚理論
    • S3は2百以上のマイクロサービスに分割されている
  • Lineは1コンポーネント毎にサーバーサイドエンジニア3,4人が多い
  • 拠点毎にマイクロサービス化するのが良い

Webサーバーサイド

  • マネージドサービスによって、担当できる範囲が広くなっている
  • 広くするかピンポイントに深くする必要がある
  • 1つの場所にフォーカスする仕事が増えている

用語

  • consul
  • サービスメッシュ

HTTPS

メンバー

  • @jxck
  • @jovi0608
  • @kjur
  • @4ma_

PKI/CA

  • シマンティックのディストラク
    • 3割のシェアを持つ会社
    • ベリサインシマンテックが買収
    • 各国に代理店を持っている
    • ある代理店にて証明書のルールに違反した証明書を確保していた
    • 対応が遅かったのでブラウザベンダー側が業を煮やした
  • CAブラウザフォーラムの体制が変わった
  • PKIかわいそう
    • そこまでたたかれることか
  • GPKI
    • リニューアルとしてCAをサブミットした?
    • 運用できていなかったことを指摘された
  • 魔女狩りに近い?
  • EV証明書は無くなると思っている
    • 認証と信頼は別
  • Let's Encryptで良いじゃんへの回答?

TLS

  • TLS1.3の正式化
    • プロトコルを大きく変えて安全になった
    • 思ったほどドラスティックに変わらなかった
      • 互換性を大事にした
      • オフィスケーション
      • IPV6
    • IETFの専門家を大量に投入した
      • 今後新しいものを作れる人がいないのでは?
    • TLS1.3はこれまでになかった作り方。これまでは一旦実装があった。そこから叩いて良くしていったが、今回のTLS1.3は研究者や暗号学者たちが一旦理想図を作ってから実装を作っていった。これによってセキュアで良いものを作ったという体験がTLS1.3で生まれた。
  • TLSデプロイ状況
    • SSL PulseによるとTLS1.3が想像より上がってきていない
  • TLS1.0,1.1を消すのはどれぐらい大変か
    • githubが1.0,1.1をやめた影響でgit cloneできなくなった
    • やってみないとわからない
    • 2020年には間に合わない
  • TLS1.3への移行
    • ガイドが出ている
    • gistによると1.2,1.3を並行して使うのがガイド
  • TLS1.4に向けて

https

  • やってこうという話が4年前
  • https厳格化するための対応(hstsなど)がどれも上手くいっていない
  • httpsは100%であってはいけない
    • alternativeがないとマジョリティがダメだった時の逃げ道がなくなる
  • httpsは通信の暗号化に寄り過ぎた

signed http exchange(SXG)

HTTP3

https://http3-explained.haxx.se/ja/

メンバー

  • @flano_yuki: Webとプロトコルの標準化 Watcher
  • @kazuho: CDN 等で使用される HTTP サーバ「H2O」の主開発者。HTTP, TLS, QUIC の標準策定に貢献 [blog]
    • fastly
    • コーディングがメインで関連する標準化活動へ参加している
  • @kaname: IETF で最新プロトコルを追っているネットワークの中の人
  • @ysnysnysn: WebSocket や Streams の実装と標準化をやっていました。最近はロボットやってます
    • 吉野
    • 今はPFNでロボット
    • 去年までAPI関連やってた

HTTP3とは

  • セマンティックすはHTTP2と同じ
  • 大きな特徴はQUICを採用している
  • HTTP2でリクエストを投げてQuicに対応していたらQuicで通信する
  • 名称
    • つけたくなる気分はわかる
    • QUICに対するバインディングの名前が変わった
    • G-QUICとI-QUICの差がわかりづらいという混乱があった
    • I-QUICをHTTP/3となった

HTTP3というプロトコルの見方

  • 妥当な進化をさせようとしている
  • ネットワーク事業者視点
    • 輻輳制御
    • NATのバイディング
    • 暗号化
  • インターネットの5%で既に使われている
  • TCPはガタがきている
    • レイテンシの壁
      • インターネットのレイテンシはあまり変わっていない
    • セキュリティの観点
      • 平文想定
  • 皆がHTTP3使い出したらどうなるか

UDPがどれだけ使いやすいか

  • ファイアーウォール
    • UDP443が通らないところが数%あったが、3年後に1/3になった
  • NAT
    • キャリアグレードNAT
    • UDPはFinが無いのでいつ切って良いかわからない
      • NRUでやれば良いのでは?
    • NATのリバインディングが怒っても通信を維持できる

HTTP3で何が嬉しいか

  • ネットワーク品質が悪い国では効果あり
  • 日本のようにネットワーク品質が良い国の効果は?
    • モバイルのパケットロスは減る見込み
    • 新しいプロトコルは有利
      • TCPに比べればアグレッシブに使える
    • 全部がHTTP3になったら良くなるのかは気になっている
    • IETFもこの問題点の認識はある
  • 0-RTTで接続ができる
  • ネットワークローミングができる
    • wifiから公衆回線への切り替えができる
  • partial relaiabilityも入れられる

Quicをどこで使えば良いのか

  • WebRTCに向いてる?
  • 動画
  • DNS

Quicが向かない分野

  • レイテンシが小さい場合は別のレイテンシの悪影響が出てくる
  • パケロスが少ない
  • 例. データセンター内の通信

Webの進化とプロトコル

  • WebSocketを作ろうとした時の苦労を思い出す
  • Httpの意味論
    • 基本的に数十年は変わらないと考えている
    • HttpNGで変えようとしたが、上手くいかなかった
  • 将来は予測つかない

HTTP3への貢献

  • よしのさん
    • ハードル高い
    • 意見出すのも大量なディスカッションに関わるの辛い
    • 意見出していってほしい
  • 日本語情報
  • 通信プロトコルの標準化は基本はクライアント・サーバーで決める
  • 実運用考えると実装者以外からのフィードバックも重要
    • サーバー運用
    • ネットワーク
  • 自分が使う立場に立ってコミュニケーションしてほしい
  • github issuesでプロトコル書いているので見てもらえると良い

資本主義をアップデートせよのメモ

WEEKLY OCHIAIの内容についてのメモ。

資本主義とは何か

  • バーチャルの対義語はマテリアル

  • 資本主義のキーワード

    ->仕組み・制度

  • 欧米では資本主義=市場経済

  • 資本主義にはイズム(主義)が含まれるが、イズムの観点で資本主義を言及している人は少ない
    • イズムはどこに行ったのか?
  • イズム->利益を再投資すべき
  • 現代の使われ方では抜け落ちている
    • アメリカの上場企業の投資の9割は自社株買いと配当に回している
    • なぜ?
      • materialを生産すると儲かる時代が終わった
  • サピエンス全史 by ハラリ
    • 再投資に回せるものをCapitalと呼ぶ
    • 再投資に回せないものをWealthと呼ぶ
  • Wealthは増えているが、Capitalが減っている
  • 個人にも当てはめている
    • お金を銀行に集めて銀行が再投資地てくれれば良いが、ゼロ金利で融資に回っていない
  • ミクロで見てもマクロで見ても資本主義のイズムが崩れてきている
  • 再分配
    • マクロ
      • 金持ちから集めて全体に回す
    • ミクロ
      • クラウドファンディング
        • 日本では購入型・寄付型が盛り上がっている
        • 金銭的なリターンを目的にしていない
        • 資本主義からの片足離脱
        • パトロンの小口化
        • クラウドファンティングで儲かった会社に市銀が追加融資
      • 数字から実体に投資する人は少ない
        • 前澤さんがやっている芸術作品への投資はウェルスへの投資?
  • 個人が投資を始めるには?
    • 新しい商品や新しいサービスに投資すれば良い
  • 企業が給料を上げるのも間接的にはキャピタルゲインになる
  • 企業の内部留保が最も資本主義を阻害する
  • マテリアルの壁を超えられない
  • ブランド・格好良いの価値
    • 周りの人が価値があると思って無くなると弾ける

Materialから見たアップデート(画一、多様化)

  • 前近代->近代
  • 近代->デジタル
  • デジタル化の利点
    • 低生産コスト
    • 易量産化
    • 易個別化
      • おすすめ
      • ネットではユーザーによって見せるものを変えられる
  • デジタル化の懸念
    • 独占企業が生まれ易い
      • GAFAの買収
      • 近代の個別化の壁を超えてきている
  • 半導体と蓄電池への投資はマテリアルの投資の成長例

イノベーション

  • 2018年のノーベル経済学賞
    • 気候変動を長期のマクロ経済モデルに組み込んだ
    • イノベーションをマクロ経済モデルに組み込んだ
      • 労働とか資本設備の増加では説明できない
      • 技術革新で説明できる
      • 発明者への個人へのインセンティブが低い
        • 特許制度の充実等の西洋的なアプローチ
  • 西洋的なアプローチ
    • 理論
  • 東洋的なアプローチ
    • 阿吽の呼吸
  • イノベーション生むのはは東洋・西洋
    • アーティスティックな感性はインセンティブで成り立つのか?
    • 自由な環境を与えられているのが強い?
    • 短期的な成果に追われている
    • 感性を育むことが主業務の成果につながる
    • 社会との循環が相乗効果を生む
    • 価値観を複数持つ人が上に立つ
  • GG無ゲー
    • 無下:シニア世代を無下に扱う
    • 無碍:物事にとらわれずに自由にやる
    • 無価:Priceless。

JAWS DAYS 2017

新訳 とあるアーキテクトのクラウドデザインパターン目録 by JAWS-UGアーキテクチャ専門支部

http://jawsdays2017.jaws-ug.jp/session/1998/

  • JAWS-UG ARCH: アーキテクチャ専門支部
  • コスト: 開発3割、運用7割
  • Route53 as the hybrid Cloud
    • ハイブリッド: AWSとオンプレに両方サーバーあり
    • PrivateIPアドレスでDNS
      • AWS Directory Service(Simple AD) -> Amazon Provided DNS -> Route53
  • AMI Maintenance Environment
    • EC2にSSHログインしないでEC2を構築する
    • qitaに投稿あり by はたのさん
    • S3で構成管理する
  • EC2, RDSで作る3層構成は維持費がかかる
  • マイクロサービスアーキテクチャ
    • サービス間は疎結合で外部インターフェース間でのみ通信
    • サーバーに状態を持たない
  • サーバーレス
    • EC2 -> Lambda
    • EBS -> S3
    • RDS -> DynamoDB
      • トランアクションは自前での実装が必要
    • 監視 -> CloudWatch, AWS X-Ray
  • サーバーを使わずに動的なWebサービス
    • Route53
    • 静的なコンテンツはS3
    • 認証はCognito
    • 動的なコンテンツはAPI Gateway経由でLambda-> DynamoDB
  • URLへのコンテンアクセス時にコンテンツ生成し、2回目以降は同じ内容のコンテンツ返す
    • S3でファイルがない時(404)は生成処理へのリダイレクト(307)を返す
    • Qitaに記事あり
  • 重たいAPI処理結果を受けて別の処理を走らせたい
    • BeanWorkのWorkerでポーリングしてLambdaで処理させる
    • Step Functionsでできる
      • 値段とAPI制限が課題?

AWS SECURITY DEATH \m/ ~セキュ鮫様からのお告げ~ by Security-JAWS

http://jawsdays2017.jaws-ug.jp/session/1512/

  • Security-JAWS
    • 3ヶ月に1回のペースで開催中
  • AWSにおけるネットワークの基本
    • Who?
      • 大喜多
      • VPN, F/Wが専門のネトワークエンジニア
    • VPC
      • 論理的に独立した自社専用のクラウド環境を作成する機能
      • 今はVPCが標準だが、昔は違った。Clastic EC2
    • Public subnet
      • インターネットと直接接続する。EIP紐付け可能
    • Private subnet
      • インターネットに繋げないが、内側から外側にGW経由で接続可能
    • セキュリティグループはステートフル
    • ネットワークACLはステートレス
    • VPN
      • VPCの各サブネットとVirtual Private Gatewayを接続数r
      • VPNの場合、AWSには2つのVPNエンドポイントがある
    • Direct Connect
      • Equinix TY2まで利用者が接続する
      • 接続ポイントからAWSまでAWS
      • 通信キャリアによりサービス形態は異なるが専用型と共用型がある
    • ソリューションラインナップ
      • TOKAIコミュニケーションズ
      • Colt
      • 大手キャリアは共用型が多い印象
  • WAF, DDOS
    • Who?
      • 吉江瞬
      • OWASP Japan Promotion Team
    • DDoS
      • 大量コンピュータが一斉に特定のNWやコンピューターに接続して落とす
      • 種類
        • L3/L4
        • L7
      • AWS Shield
        • 2016/12リリース
        • CloudFrontでShieldオプション有効化
        • オンプレでも利用可能
        • 防御対象: CloudFront, ELB, ALB, Route53
        • 監視: 常にモニタリングしてベースラインの作成、異常検出
        • 料金
          • Basic: 無料で利用可能
          • Advanced: 1年間の利用コミットで月額3000ドル
    • WAF
      • レガシーなFWやIDS/IPSでは防ぐことができない不正な攻撃からアプリケーションを防御する
      • Apache Struts2脆弱性
        • 都税支払いサイトからカード情報流出
        • WAFにて対応はしていた
      • できること
      • 残念
        • キメ細かい設定ができない。ルールを正規表現ができない。POST見れない。WAF検知ログは100件まで
      • セキュリティ面ではAWS WAFに不足があるので、SaasやWAF on AWSも要検討
  • AWS Config
    • Who
      • 森永大志
      • クラスメソッド
    • Configとは?
      • 構成管理、変更管理
        • 関係性の閲覧
      • 対応サービス: ACM, CloudTrail, EC2, EBS, Systems Manager, ALB, IAM, RDS
    • ユースケース
    • 設定のチェックを行うサービス
      • AWS Config Rules
        • 設定が正しいかを判定するルールが設定できる
        • マネージドルール
        • カスタムルール
          • 後ろにLambdaなので、なんでもできる
          • githubのawslabsにもAWS公開のルールあり。2017/3現在34個あり
      • Config関連のブログあり

EXCEL構成管理からの脱却と次世代MSPとDevOps 2.0 by OpsJAWS

http://jawsdays2017.jaws-ug.jp/session/1518/

  • EXCEL構成管理からの脱却
    • Who
      • 会沢康二
    • OpsJAWS
      • 運用というワードに反応した全ての方
      • 作ったものをどうやって維持/管理していくか
    • DevOps
      • 開発と運用が強調し合うことで開発/運用するソフトウェアによって、ビジネスの価値を高める
    • エンタープライズでDevOps
      • 単純移行したシステムも継続的な最適化が求められる
      • 失敗例を成功に変えるAWSアンチパターンのご紹介2016
    • Systems manager
      • 概要
        • AWS管理外のOSより下位のレイヤーの部分をAWSで管理
        • ログイン無しで利用できる
      • ミドル、各種SW部分はDev/Ops間でお見合いになりがち
        • Systems managerで解決
      • ソフトウェアインベントリ
        • AWS Configとの連携
        • SWインストールするとAWS Configに伝わる
      • AWS Config -> AWS Config Snapshot(json) -> AWs構成パラメーターシート(Excel)
      • Run comand
      • パッチ管理
        • 必要なパッチが当たっているか監査し、適用
        • 簡易的なWSUS
    • Opsもコードを書いてて作業メンテを減らしていこう
  • 次世代MSPとDevOps 2.0
    • Who?
    • MSPとは
      • Management Services Provider
      • 記号が保有するサーバーやネットワークの運用、監視、保守を請け負う業者
      • 監視して生涯を見つけてつうしし、スペック提案
      • パッチ適用して稼動確認
    • 次世代MSP
      • プロアクティブ監視
        • 障害を事前に検知する
      • 予測 -> 事前提案 -> 障害防止
      • 次世代MSPツール
        • 予測
          • Zabbix 3.x
            • 1週間後や1ヶ月後のリソース越え予測
          • CloudWatch
            • データからAIから予測
        • サーバーレス
          • CloudWatch
          • AWS Config
            • 構成変更の検知
        • 分析と提案
          • X-Ray
            • アプリに埋め込むとインフラ内のどこが遅いかを検知する
            • インフラ内のボトルネック検知
          • Grafana
            • 可視化ツール
            • Zabbix, CloudWatch以外に気温、天気等の外部要因と組み合わせて見れる
    • 次世代MSPとDevOps
      • 手法とプロバイダーは両立するのか
      • Opsの成長に付き合えるMPSが求められる
    • DevOps 2.0
      • DevOpsのイメージは運用の負荷が大きい
      • 基盤構成が柔軟化 -> 構成管理サービス
      • スピードアップ -> 監視自動化
      • 運用から開発への提案がされるようになる(2.0)
        • キャパシティ変更
        • セキュアプログラム
        • パフォーマンス改修
        • アーキテクチャ変更
    • まとめ
      • 次世代MSPはツールではなく仕組み
      • 次世代MSPでOPSが強くなる -> DevOps 2.0 -> OpsDev

6年前のその時、クラウドで何ができたのか 〜JAWSとタイガーチーム〜

http://jawsdays2017.jaws-ug.jp/session/1735/

  • SORACOM
  • 赤十字社
    • 関西淡路大震災は8000億円の義援金
  • 震災直後の日本赤十字社の様子
    • 第3次救護体制
    • 現金書留多数
    • 想定外
      • みずほのシステムダウン
      • 日赤への義援金
    • JAWS-UGタイガーチーム誕生秘話
      • 3/3に東京リージョンリリースしたばかり
      • AWSのCEO Andy Jassyにサーバー提供の直訴メール
        • すぐ返事きたが、2つの条件つき
      • JAWS-UGをまとめれば良いのでは?
  • タイガーチームをこれほど早く立ち上げることができたのか?
    • JAWS-UGコアメンバーの横つながりがあったから
    • 初期のパートナーが会社を上げて応援してくれた
  • 次の災害時に何ができるのか?
    • IOT
      • 被災地の情報端末向けのSIM提供
    • 野良キャッシュ、ダメ。絶対。
  • 普段のネットワークが大事
    • 人道の敵
  • 人間を救うのは、人間だ。

IAM 権限をこえて

http://jawsdays2017.jaws-ug.jp/session/1792/

  • IAMとは何か
    • 利用者の認証とアクセスポリシーの管理
    • ルートユーザーを使わず、IAMユーザーを作成し、権限を割り当てる
    • IAMユーザーとIAMグループが存在
    • パーミッションはIAMユーザー/グループどちらにも設定できる
      • グループにパーミッションを割り当てて、ユーザーは利用しないのがセオリー
    • IAMポリシー
      • JSON形式で記述
      • AWS管理ポリシー
        • AWS側で勝手に変更される場合あり
    • アクセス可否の決定ロジック
      • 明示的なDeny > 明示的なAllow > 暗黙のDeny
    • IAMロール
      • サービスやアプリケーション等に捜査権限を付与する仕組み
      • IAMユーザー、グループとは別のもの
    • ID連携(Identity Federation)
    • IAMベストプラクティスあり
  • Policyたち
    • ルート権限はやばい
    • 書式
      • JSON形式、IAM Policy言語
    • 管理ポリシー
      • スダンドアロンポリシー
      • 種類
        • AWS管理ポリシー
          • 機能追加も自動でしてくれる
          • 例. EC2 Full Access, EC2 Read Only
        • カスタマー管理ポリシー
    • インラインポリシー
      • 自身で作成及び管理するポリシー
    • Statement
      • Sid: Statementブロック内で内で一意で有れば良い
      • Action: 許可/拒否するサービスのアクション
      • Resource: Amazonリソースネーム(ARN)
        • AWSリソースを一意に識別
    • IAM Policy Simulatorは良い
    • Become an AWS IAM Ninjaの RE:Invent資料は参考になる
  • IAMの鼓動はログ
    • AWSアカウントの不正利用
    • 適切でないAWSアカウントの存在
    • AWSアクティビティの監視
      • AWS CloudTrail
        • AMI呼び出しのロギング
        • API lookup
          • S3に保存されるJSONログの一部情報のみ
          • 7日間のみ
      • AWS Config
        • AWSリソースの構成管理
    • S3ログ解析
    • 認証情報レポート
      • 例. パスワード認証とアクセスキー認証が両方有効
      • パスワード認証が使われた形跡がない
      • MFAが設定されていない

AWSデータベースアップデート 2017

http://jawsdays2017.jaws-ug.jp/session/1220/

  • Amazon ElasticCache
    • Redis Cluster
      • 3.5TB
      • 4.5 million writes per second
      • 20 million reads per second
    • 海外では永続化データの場所として利用事例多い
    • 今後も永続化向けのアップデート予定
  • Amazon Aurora
    • 既存
      • 性能面でMySQL5.7を圧倒する
      • PostgreSQL
        • 現在Preview
        • PostgreSQL 9.6.4との完全互換を目指している
          • 将来使いたい場合は9.6.4以降にしておくと良い
      • Performance Insight
        • クエリパフォーマンスの評価
        • Postgre Aurolaから導入し、順次他DBに広げていく予定
      • ゼロダウンタイムパッチ
        • アプリケーションから見てコネクションを切られずにDBバージョンアップ
      • OnlineDDL
        • Alterが1秒以内
    • 今後
      • Online point in time restore
        • 動いているAurolaを特定時点にロールバック
        • ログを見えなくすると過去の段階に戻せる
        • 現在は数時間前まで対応する予定
      • Database cloning
        • 1TBのデータをcloneしても1TB文の課金のみ
        • 変更文のみ課金される
        • 本番データでテスト
      • Aurora Auditing
        • 監査ログを有効にしてもパフォーマンス落ちない
    • 最近の改善
      • インデックスツリー作成の高速化
      • Cached read performance
      • Insert Performance
  • AWS Database Migration Service
    • Fan-in
    • 片方がAWSにあれば利用可能
    • Schema Convertion Tool
    • 20000以上の実績あり
  • Amazon Athena
    • サーバーレス
    • prestoが動いてる
    • oltpではなくolap向け
    • オンメモリで処理する仕組み
    • jdbcドライバあり
    • Viwer
      • amazon quick sight
      • spice
      • redshift,emr,athenaに繋ぐ
  • AWS Glue
    • ETL(Extract,Transform,Load)ツール
    • フルマネージドETL
    • データ変換も可能
    • pythonコードをロードしてエラーハンドリング等を実施

dots.2周年記念パーティ

言語デザイナーが見る未来 by Matz

Who are you?

  • 松江市名誉市民
  • IT総合戦略本部委員

テクノロジーの変化

  • パソコンのメモリは640KBで十分 by Bill Gates
  • 20数年前のスーパーコンピューターはiphone5程度

エクストリーム未来予測

  • ポケットに今のスパコンが入ったらどうなるか

プログラミング言語の進化

  • FORTRAN(1954)
  • Lisp
  • COBOL: 帳票、データ
  • C(1972): OSをかけるようになった
  • Pearl(1986)
  • Erlang(1986)
  • Java,JavaScript,PHP,Ruby(1995)
    • Windows95が出て誰でもインターネットにアクセスできるようになった
  • できなかったことができるように
    • 人間の脳でもできるという意味
  • できたことをできないように
    • goto

未来へのキーワード

  • C100K問題
  • テラメモリ問題
  • ペタデータ問題
  • 10000 Cores
    • プログラマがマルチコアを活用しなければならない
    • 非決定性
      • ハイゼンバグ
  • 新技術を身につける力が重要
    • 検索力
    • 世界観
      • 大枠を把握すると新しい技術がどこにはまるのかを理解する
    • 変化しないものの方が大事

QA

  • Matzが見る未来
    • 20年、30年後はプログラミングしないとできない領域が減っていくのではないか
  • 注目しているフレームワークは?

    今後エンジニアに求められるスキル/考え方

    • 未来に必要な技術とは?どんな技術を身につけていくべき
      • クズさが必要
      • 変わらないもの。レイヤーの下の方は変わらない。PC自作。ネットワークの知識。
        • 夢中になってつきつめていく。
      • 新しい技術に追いかけていくべき
        • 好きなことをつきつめている人に任せるべき
    • 未来につながる、もってほしい考え方は
      • 自分一人だと限界がある。
      • 10年後、15年後はどうなるかわからない。何のためにプログラミングしているのかを忘れない。
      • 自分の楽しいことをしたい。捻じ曲げて自分の楽しい方向にもっていく。
    • どう働くべきなの?会社とし働き方を変えるべきなの?
      • エンンジニアの得意なところは囲ってて良いのか?色々なところいっても良いのでは?
      • 労働のオープンソース
      • エンジニアは自分のパフォーマンスが出せるようにする面でもプロフェッショナルであるべき
    • 今後はこんなOSSが登場するのでは?ほしいOSSは?
      • Hadoop, Sparkの後継
      • Meteo
        • Active Valueというコンセプト。データのアップデートやトリガーは自動でやってくれる。人間はレイアウトとデザインだけ考えれば良い。
      • HashiCorp, ElasticSearch
        • 運用面の知見で価値を届ける
      • 売り物でも気軽にプルリク送れるような関係性が面白いのでは
    • 今後注目されるような開発コミュニティは?
      • 日本人がいないコミュニティに入っていくと良いのでは
      • 参加する人を増やしたい。初めのいぽを手助けするような活動をしたい。
      • オープンソースに必要なのは炎上力
    • Hard Ware
      • ネットワークプログラミングで世界が変わった
      • HWエンジニアと働くのは共通知識がないから大変。ただHWの遭遇こそがIOT。