kaakaa Blog

この世は極楽 空にはとんぼ

builderscon2018 - 1日目

概要

まとめ

  • "Developers didn't trust micro services architecture"というフレーズが印象的だった。MSAはDevでも信用できないもので、"導入"とかするもんでなく、しっかり育てていかないといけないんだろうなぁ
  • パスワードレスも環境揃ってきてお試しぐらいならできそうだけど、デバイス間のアカウント共有とか機種変とか実用的な部分考えると導入難しおそうだなぁ
  • JavaCardは制限強くて辛そうだけど、そういう中でものづくりするのがエンジニアリングだなぁ。ネタ込みで楽しかったです。
  • Ruiさんはスタイルいいし、声もいいなぁ。 "データ構造重要。同じコードは複数回書く。最適化は最小限に。オーナーがコードに責任を持つ。" 非常によくわかります。
  • 去年も参加したけど、相変わらず運営さんがテキパキなので信頼感ある。
  • ランチセッションは行列すごくて早々に諦めた。抽選制とかどうですかねぇ...
  • 終日のカンファレンスで会場内飲食禁止は辛い、特に飲み物。(イベントホールはOKだけど、初日はイベントホール行かなかったので）

Envoy internals deep dive

  • Matt Klein(@mattklein123)

  • Lyft

  • what is Envoy

  • Before Envoy
    • (~5yrs ago) client - |internet| - AWS ELB - PHP/Apache(Monolith) - MongoDB
    • (~3yrs ago) PHP/Apache(monolith) - (AWS Internal ELB | Mongo/Dynamo ) - Python
      • Not Simple. Microservice with monolith
      • Problem:
        • multi lang and framework
        • Many Protocol (HTTP/1|2, gRPC,DB,caching...)
        • Black Box LB(AWS ELB)
        • Lack of consistent Observability(stats, tracing, logging)
        • poor the capability for ditributing (retry, circuit breaking, rate limiting, timeouts)
        • minimal AuthZ/AuthN
        • Extremely difficult to debug
        • Devs didn't trust MSA
    • envoy
      • transparency to application. easy to determine the source of the Problem
  • envoy design goals
  • architecture overview
    • Envoy config management via xDS API
      • xDS == * Discovery Service. E.g.: Listener DS / Cluster DS
        • gRPC streaming. JSON/YAML REST via proto3
      • central management system. avoid per-proxy config file hell
  • threading model
    • c10k, asynchronous is harder
    • 3 kinds thread
      • Main thread
      • Worker thread
      • File flush thread
    • designed to be 100% non-blocking / to scale to massive parallelism
    • RCU: Read-Copy-Update
    • TLS: Thread Local Storage
  • hot restart
    • Full binary reload without dropping any connections
    • f:id:kaakaa_hoe:20180908231915j:plain

  • Envoy stats

  • refs

パスワードレスなユーザー認証時代を迎えるためにサービス開発者がしなければならないこと @ritou

  • @ritou(OpenID foundation / mixiの人)
  • パスワード認証を辞めるべき理由
  • パスワードレスへの移行
  • 現状
    • パスワード認証/多要素認証/リカバリ
    • ソーシャルログイン
  • 最新動向

  • パスワードレスの実現

    • どの認証方式を使うか？
      • メール/SNSで認証コード送信・ソーシャルログイン・バックアップコード・モバイル端末指定
    • UXは？
      • 登録
        • パスワード設定の１ステップが削減されるぐらい？
        • リカバリー用のメール/SMS設定は必要になる。
      • ログイン
        • ユーザー識別情報によりログイン方法が変わる。Googleのような感じになる？
    • 「パスワード確認」相当の処理は？

  • Q: AuthenticatorはUSBで接続するものがあるが、スマホなどでも同じ認証を通したい場合どうするのか？

    • A: デバイス自体がAuthenticatorになるなどするのでは？
  • Q: Authenticator自体や送信経路のセキュリティが問題になる場合もあるのでは？
    • A: 中間者攻撃などのリスクはある。リスクが整理されるのが理想。
  • Q: 複数のデバイスで複数のサービスに登録していた場合、無効化する場合は全て個別にやっていかなきゃいけないのか？
    • A: 現状は特にない
  • Q: Authenticatorの登録情報をリカバリしたい場合の代替策の推奨
    • A: 特に決まってはいない
  • Q: スマホなど端末を乗り換えた場合、古い端末情報は自動で無効化されるのか？
    • A: サービス側の実装による。
  • Q: 社内でパスワードレスを提案したときに却下された理由は？
    • A: 「ショッピング系サイトなので、ユーザーが新しい認証方式に嫌悪感を示すのでは？」というふわっとした理由
  • Q: PGP, GPGなどの古い話はidConで話されているのか？
    • A: 扱う範囲は広いので話が出ることもある。
  • Q: OAuth2.0やOpenIDなどは減っていくのか？
    • A: パスワードレスと重なっている部分はあまりないので

Java Card

  • @moznion
  • JavaCard: クレカ / SIM / B-CAS?
  • JavaCardはSmartCard(ISO 7816)の内のIntelligent Smart Card
  • UICC(Universal Integrated Circuit Card)
  • Java Cardの歴史
    • v2.1 - 1999年リリース。20年近くの歴史
    • v3.0.5 - 2015年リリース。最新版。
    • JCRE上で動くバイトコードはJVMのバイトコードのサブセット
    • カードがGCをサポートしているか否かでGCされるかされないかが決まる
  • JavaCardMemory
  • Java Card JVMはshutdownしない
    • 永遠にクロックが来ない状態で動作し続けている
  • Environment
  • カードへの書き込み
    • Cardの書き込みには認証鍵が必要(個人ではもらえない・・？)
    • Amazon.comとかで100枚 $300とかで買える
  • Q: JavaCardコードでfor文は使える？
    • A: 使える。インデックスはshortにしないとまずそう
  • Q: JavaCaadが壊れた場合のリカバリはできない？
    • A: EEPROMが壊れているのでリブートしても治らない。交換対応。
  • Q: shortにキャストしないと何の型になる？
    • A: 数値リテラルはキャストしないとintになるかも
  • Q: APDUにはshortフォーマットとextend lengthがあるフォーマットがあるが、extendの方では何ができるか？
    • A: 使ったことが無いので分からない
  • Q: JavaCard上ではどういうアプリケーションが動いてる？
  • Q: 開発時に使えるエミュレーターなどはあるか？
    • A: ある。が、商用のアプリケーションしかないと思う。
  • Q: JavaCardコードの特徴は？
    • A: javacard.frameworkをimportしていればjavacard
  • Q: JavaCardの将来性は？
    • A: SmartCard上の処理系で使えるのがJavaCardぐらいでは？クレカ/SIMが絶滅しなければ生き残れるのでは？
  • Q: コードがJavaっぽくないが、なぜスマートカードの実装がJavaなのか？
    • A: スマートカードアプリには色々な処理系があったが(Lispなど)淘汰され、JavaCardが生き残ったのでは？
  • Q: E-SIMはJavaCardとして動く？
    • A: E-SIMもJavaCardで動く。
  • Q: EEPROMを壊さないようにコーディングで気を付けている点は？
    • A: 洗練された方法が無いので人間が頑張る。transient arrayを使ってRAMに書き込むようにする。耐久テストをする。
  • Q: 複数のAppletを協調動作させるには？
    • A: Appletが動かしたいAppletに切り替えるAPDUを流す(？)。別のAppletがselect()されると勝手にdiselect()される。
  • Q: JavaCard内の実装は組織によって多様なのか？
    • A: 弊社ではヘルスチェック用のApplet機能を追加して、プレスリリースした。

lld

  • lldはLLVMサブプロジェクト
  • FreeBSD, Chrome, FireFox/Windows, Rust/ARMなどで採用されている
  • ELF(Unix)をターゲットに高速化されたGNU goldよりも2~4倍速い
  • lld/ELF 3万行ぐらい(goldは20万行)
  • pecoff.PDF
  • Linkers & Loaders | JohnR. Levine, 榊原 一矢, ポジティブエッジ |本 | 通販 | Amazon
    • 本を読んでも全くわからない
    • クラッシュする実行ファイルを生成するものから、徐々に機能を足していく
  • 無駄な抽象化により遅くなる
  • 書き直しを提案。コードを書かない人たちが説得しにくる。開発者を止められない。
  • 「データ構造が重要。データ構造が決まればコードが決まる。」Rob Pike
  • 早くてシンプルなコードを書くために
    • データが先。コードは後。
    • ２回書く(1度目の経験を活かす)
    • 最適化する箇所を最小に止める(大半は読みやすさを重視する)
    • オーナーが責任を持ってコードを綺麗に保つ