#builderscon 2019 参加レポート
今年もbuildersconに参加してきました。
参加したセッション内容のメモと簡単な所感、全体所感を書き残しておきます。資料が公開されているものはリンクを張っておきました。
※一部、私個人の解釈でメモしているものもあり、発表者の方の本来の意図とズレているものがあるかもしれませんがご了承下さい。
昨年と一昨年の参加レポートのリンク。
本編1日目
Open SKT: メルペイ開発の裏側 - builderscon tokyo 2019
資料: Open SKT: メルペイ開発の裏側 / builderscon tokyo 2019 Open SKT : Speaker Deck
内容
- 決済はお金のトランザクション管理が難しい
- SKTってなに？
- Super Kazegusuri Time
- オンボーディングも兼ねた社員研修
- 目標やポリシー、アーキテクチャ、開発体制、開発手法を伝える場
- メルペイの開発で重視していること
- インフラのように安定して信頼できるシステム
- サービス開発をメインにしない
- アーキテクチャ
- 分散システムにおけるトランザクション
- 難しい
- 中央で一元管理する方向に
- エラー処理も含めたモデルの一般化が必須
- エラー処理を例外として扱わない
- お金のモデルは全て状態遷移モデルを定義している
- 引き算はいきなり確定させるとキャンセル時など不都合が生じる
- いったん確保、その後に確定する
- 不正検知
- 開発フロー自体はメルカリと共通だが多少違いがある
- 業界全体のレベルをあげるために事例をどんどん公開していきたい
所感
メルペイのシステムアーキテクチャ、決済サービスの難しいところ、メルカリとの開発体制の違いなどが語られたセッションでした。
お金を扱うという特性から信頼できるインフラとなるようなシステムにするために、コストをかけてもより安全に開発していくという信念がとても伝わってくる内容でした。
サービスの安定性の指標としてSLOを重視するという話がありましたが値の設定とそれの運用はとても難しそうだと思いました。SLOをどのように設定し、どのようにアップデートしていくかの知見を今後是非聞いてみたいですね。
Android Architecture Componentを使って、改善・効率化するAndroidアプリ開発 - builderscon tokyo 2019
資料: まだ未公開？
内容
- AACの全体像
- 便利に使える、公式、モダン、部分的に導入可能
- Android Architecture Components : Android Developers
- Data Binding
- xmlからBindingクラスが生成される
- Lifecycle-Aware Components
- @OnLifecycleEvent(...)を使ってどのライフサイクルイベントでそれを実行するか書ける
- ライフサイクルを外だしできる
- Live Data
- Lifecycleを考慮してくれるObservable
- ViewModel
- 画面が回転したとき画面は再生成されるがViewModelは変わらない
- Room
- SQLiteのオブジェクトマッパー
- WorkManager
- 少し長い処理や遅延できるものを実行するときに使える
- 電力状態などデバイスの状態で実行するかどうか決められる
- Paging
- ページネーションに必要なPageのデータを持てるもの
- Navigation
- iOSでいうSegue
- 既存プロダクト(Wantedly People)への導入とその変化
- RealmからRoomへ
- Roomの方がテスタビリティが高い
- MVPからMVVMへ
- ViewModel
- WorkManagerの利用
- 端末の連絡先と同期部分で利用。遅延実行することでUXの改善に繋がった
- RealmからRoomへ
所感
Android Architecture Componentの概要とWontedly PeopleのAndroidアプリでどのように使っているのかが語られたセッションでした。
最近Android開発に関する情報はあまりちゃんと追っていなかったのでいろいろと知れました。公式でこれだけ用意されている状況なので、新規でAndroidアプリを開発するときはまずは公式のものを使ってどこまでできるかを考えて、それでまかないきれないものに対して他のライブラリを使うかどうか検討していくのが良さそうだと思いました。
Android Architecture Componentはいきなり全部入れないで自分たちに必要なものを徐々に入れていけるので、今回の発表の例のように既存の実装を置きかえていきやすいのもGoodですね。
WebAuthn/FIDOのUX徹底解説 ~実サービスへの導入イメージを添えて~ - builderscon tokyo 2019
資料: WebAuthn/FIDOのUX徹底解説 ~実サービスへの導入イメージを添えて~ / builderscon tokyo 2019 ritou : Speaker Deck
内容
- パスワード認証にはさまざまな問題がある
- ワンタイムパスワード認証
- 結局はユーザーが入力する必要がある
- FIDO
- ローカル認証を利用
- 公開鍵暗号方式を用いた登録と認証
- FIDOのユースケース
- パスワードレス認証として(所持+ローカル認証)
- 追加認証として(所持)
- FIDO 2
- WebアプリからもFIDO
- WebAuthn
- FIDOを利用するサービス側が呼び出す
- CTAP
- セキュリティキーとやり取りするための仕様、ブラウザが実装
- WebAuthnのフィッシング耐性
- origin単位で鍵ペアを生成しているのでそもそもフィッシングサイトにログインできない
- WebAuthnのUX
- Q&A: Authenticator自体が脆弱性を持っている場合もあるのでは？
所感
WebAuthnの認証フローを実際に実装しているサービスの認証画面を元に説明してくれるセッションだったのでとても分かりやすかったです。
WebAuthnを使っているといっても思ったよりサービスごとにフローがバラバラで分かりづらい状況ということが理解できました。ITリテラシに疎い人からしたら現状この仕組みはかなり難しい気がします。今まではAuthenticatorの普及だけが問題だと思っていましたが、それだけでなくこのあたりのフローも業界内である程度統一できないとなかなか普及は難しそうだと感じました。
ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ - builderscon tokyo 2019
資料: ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ #builderscon : Speaker Deck
内容
- SoRとSoEを各設計原則や設計パターンをベースに言語化したかった
- モデルとは何か
- SoRとSoEでは扱うモデルが違う
- 解決した問題領域から必要と思われる情報を抽出して記号化、可視化したもの
- どのようなモデルが有効化は対象とする領域に依存する
- E-コマースサービスで考えると
- CQRSとの関係
- SoR/SoEという分類とCommand、Queryの非対称性に着目した分離は共通している部分が多いのでは？
- SoR/SoEの実践
所感
モール型のE-コマースサービスを例にして、アクターの分け方やSoRとSoEのシステム間連携をどのような考えで行うかが説明されたセッションでした。DDD本とClean Architecture本をあらためて読み直して考えたくなるような内容でした。
SoRとSoEって確かにバズワードっぽい感じになっている感じもするのでこうやってきちんと設計に落とし込んで考えられるようにするというのは非常に大事なことだと思います。
「B2BがSoRで、B2CがSoEなのか？」のような質問があった気がしますが（うまく聞き取れなかったので違っていたらすいません）、そういう区分ではないと思っています。B2B、B2CのシステムそれぞれにSoE、SoRの分類があると考えます。今回の発表にもあったようにアクターで分けて考えればそれは自明だと思います。そういう意味でもこの発表の内容はとても分かりやすかったです。
本編2日目
レガシーサーバーを現代の技術で再構築する - builderscon tokyo 2019
資料: レガシーサーバーを現代の技術で再構築する/builderscon2019 : Speaker Deck
内容
- SVNとかRedmineなどがのった古いサーバーを何とかする話
- やらないことを決める
- URLは維持する
- マネージドサービスを使っていく
- 4年おきくらいに一応再構築はしていた
- レンタルサーバー → オンプレ → EC2
- Redmineに気軽にモンキーパッチを当てるなどしてとりあえず便利にしてしまっていた
- やらないことを決める
- EC2を分解しマネージドサービスで再構築
- ALB導入
- EBSをAmazon EFS/S3に置きかえ
- ファイルじゃ無いといけないものはEFS、アプリを書き換えられるものはS3
- アプリをECSを使ってコンテナ化、ALBから振り分け
- ALBでルーティングし、URLを維持したまま段階移行が可能に
- ファイルがディレクトリに大量にあるとlsコマンドが返ってこない
- findを使いましょう
- 認証どうするか
- いろんなものにhtpasswdを使っていた
- 最近のものはG Suite
- htpasswdはどうにもできないのでGitHubでバージョン管理、Circle CIでworkflowを実行しサーバー上に配置
- FargateからEFSは現状使えない
- 定期的にシステムと業務を見直し、維持するもの切り捨てるものを決めることが大事
所感
歴史のあるサーバーをモダン化していくにあたっての取り組みやそこで得た知見が語られたセッションでした。
Redmineで使っていたプラグインが原因でバージョンアップが困難になったという話はあるあるだなと思いました。こういうプラグインって便利だからついつい入れちゃうんですよね。で、数年後もうメンテされて無くてどうしようというパターン。利便性との天秤がとても難しいので苦労が伝わってきました。
質疑応答で出ていた、使っているか使っていないのかよく分からないものはとりあえず黙って止めて文句がでるか様子を見るという方針は私もやったことがあるので皆やってるんだとちょっと安心しました。
htpasswdをGitHubで管理してることがちょっと気になってつぶやいていたらfujiwaraさんから返事を頂いたので貼っておきます。
hash化はされているのと、リポジトリやS3の権限を絞ってるのでEC2にログインして見られるのと同等の公開範囲にはなってます。ランダム発行したパスワードしか付与してない(ユーザに決めさせてない)というのもあり、許容範囲かなと思ってはいます(が、なくしたいですね
— fujiwara (@fujiwara) August 31, 2019
スーパーカミオカンデの開発と運用 - builderscon tokyo 2019
資料 : Introduction to Super-Kamiokande for geeks(?)
内容
- クオークはアップクオークとダウンクオークがある
- こいつらがいると世の中のもの全部作れちゃう
- クオークとレプトンはそれぞれ3世代ある
- なぜ3世代かは誰も分からない
- 陽子は10の80乗年後に壊れると言われている
- ニュートリノはありふれた粒子、重さはほぼない
- 太陽はたくさんニュートリノを作っている
- 地球の中心からもニュートリノは来ている
- チェレンコフ光の輪っかを見るとどこから来ているか分かる
- チェレンコフ光は一瞬しかでない
- スーパーノバでニュートリノが大量の放出される
- ベテルギウスがスーパーノバになったらヤバい量のニュートリノが放出される
- スーパーカミオカンデの光電子倍増管(デカい電球みたいなやつ)は機械で作れないから人が作っている
- データ取得のためのシステムのインフラ
- スイッチはQoSが切れるものを選ぶ
- ケーブルの長さが1m違うと5ns変わっちゃう
- 全てのデータを取っておかないといけない
- CPUはTotal2212コア
- 計算にはFortran使っている、新しいのはC/C++
- ソースコード管理はSubversion
- ハイパーカミオカンデを建設予定。2027年には観測開始できる予定
所感
本当に初めて聞くような内容でした。まさに知らない世界。でも発表もテンポがよくとても楽しく聞かせていただきました。
前半は量子力学的な話、後半はデータ取得/保存のためのIT寄りの話でした。
こういう世界でもインフラ周りやソースコード管理などで考えないといけないことは割と同じ感じで「おーこういう分野の仕事や研究においても今やってる知識って使えるんだ」と思いました。まあでてくる単位の桁は違いましたけど。
入門サービスメッシュ - builderscon tokyo 2019
資料 : builderscon Tokyo 2019: Intro Service Mesh : Speaker Deck
内容
- サービスメッシュのような概念は今のコンテナブームの前からあった
- マイクロサービス化により分散化し複雑なシステム構成に
- 今までのツールデは対応できない運用課題が増加
- Observability
- Failure recover、fault isolation
- Finagleに代表されるライブラリアプローチの興隆
- 自前で作っている会社も多かった
- 実装の一貫性の問題も
- 歴史
- 2016年にLinkerdがリリースされたときに初めてサービスメッシュって言葉が使われた
- 2016年9月にEnvoyがPublic release
- 2017年5月にIstioがPublic release
- EnvoyはProxyの実装
- Control Planeは自分で用意する必要がある
- 自作
- Istio
- マネージドサービス: Traffic Director、AppApp MEsh
- Consul
- Control Planeは自分で用意する必要がある
- Linkerd v2はProxy、Control Plane両方持ってる
- サービスメッシュ選球眼
- 自分たちの規模を見据える
- 大規模になるなら分散化が重要、高度に分散化した環境では通信層での仕事は必須
- 自分たちの環境を分析してソフトウエアを選ぶ
- 自分たちのやりたいこととIstioでできることの差分は？などを考える
- 自分たちの規模を見据える
- Service Mesh is not for Kubernetes only
- ただし、ハイブリッドクラウド環境などで使える製品はほとんどないし事例も少ないので頑張りが必要
所感
サービスメッシュ登場の背景や考え方をざっと学べるセッションでした。
コンテナ技術の流行から出てきた概念だと思っていたのですがそんなことはなくそれより前からあった概念だということに驚きました。「Service Mesh is not for Kubernetes only」という言葉は今まではサービスメッシュ=コンテナで使うものという思考しかなかったので考えを柔軟にするいいきっかけになりました。
もしもハッカーの「サイバー攻撃日誌」が読めたら - builderscon tokyo 2019
資料 : 公開なし
内容
- Red Teamサービスとは
- 攻撃例のケーススタディ
- SNS使って従業員の情報集めてメール送信
- 権限昇格させる
- SYSTEM権限で動作するサービスのEXEを置きかえ
- パスワードハッシュの取得
- ローカルアカウントのハッシュダンプを取得し解析
- IT管理者の特定
- 座先表や社員番号、機器番号等が載っているファイル等を探して推測
- 横断的侵害
- 取得済みアカウントによるリモートコマンドの実行
- ドメイン管理者アカウントの取得
- Mimikatz: メモリ上の認証情報を取得
- ドメインコントローラーに侵入
- 全ユーザーのパスワードハッシュを取得、解析
- これを使ってWebメールにアクセス、システム構成図などを探す
- 2要素認証が設定されているとここで詰まるので対応策を考える
- ユーザーの端末はもうのっとっているので2要素を突破しているユーザーの端末経由で入り込む
- ユーザーがお昼などで席を外している間にRDPで入り込んで操作
- 防御側が理解しておくべき事
- 検知の仕組み
- 後から分析できる仕組み
- 危険度を判断できるスキル
- 初動、情報共有が早いと侵入に苦労する
- Hardening projectで練習できる
- 各チームにECサイトが与えられ主催者がひたすら攻撃、それを守る
- わざわざそこまでやるやつはいないだろうと誰かが言うたびにわざわざそこまでやるやつが現れる
- QA: Macの場合はやはり大変なのか？
- ADに参加していない場合も多く、マシン単体で動作していることが多いので他のマシンに攻撃を展開していきづらい
- QA : 秘密の質問とかがあるだけでも侵入しづらいって思ったりするのか？
- たいがいマイドキュメントとかにメモがあるので侵入が難しくなることはない。2要素認証だと本当にやりづらい。
所感
ここまで詳細な攻撃方法を聞けるとは思っていなかったのでとても面白かったです。個人的には今年のベストセッションでした。攻撃のケーススタディはずっとなるほどー！という声を口に出してしまっていました。
やはり2要素認証は使える場合は使うべきってことがはっきりしました。なぜか使わないという謎の選択を過去実際に見てきたのでこのセッションをそのときの関係者に見せたくて仕方なくなりました。
あとは、検知の仕組みをきちんと整えて対応できるようにすることもあらためて大事だと思い知らされました。本気で攻撃されたらやられるときはやられるので、いかに早く反応できるかが勝負になってきますからね。
全体所感
3年連続で参加していますが、本当に毎回知らないことを聞くことができるカンファレンスです。
特に今回は、スーパーカミオカンデのセッションともしもハッカーの「サイバー攻撃日誌」が読めたらのセッションの2つに感銘を受けました。まだまだ自分の知らない世界はたくさんありますな。
会場はいつもの慶応日吉キャンパスではなく北千住の東京電機大学のキャンパスでの開催でしたが、ベンチなども割と多くてちょっと休憩することも日吉よりはできたので快適でした。
運営の皆様、発表者の皆様、参加者の皆様、楽しいカンファレンスをありがとうございました！今年も本当に刺激を受けました！
(おまけ)運営フィードバック
最後に運営面で気づいた点をメモ。
