Developers Summit 2013レポート(3)
デブサミ2013 2/15分後半です。
5msの中身を公開！〜ネット広告配信と支える職人達〜
RealTime Biddingとは
- 1.適切な広告選定・入札額決定
- どの広告を入札するべきか
- 落札しただけではダメで、クリックして成果が必要
- いくらで入礼するべきか
- 上げる: 配信量増○、コスト高×
- 下げる: 逆
- どの広告を入札するべきか
MicroAd BLADEの特徴
- MicroAd BLADE
- 2011年6月から
- 4000社をこえる広告主
- リターゲティング/オーディエンスターゲティング広告
- retargeting
- 広告主サイトへの再来訪を促す広告配信手法
- audience targeting
- 潜在顧客をターゲットとして広告を配信する
- 統計的手法により、どういう人が興味を持っているかをためる
- 広告主はどのあたりに配信したいかターゲットを設定
- 設定に合う人に対して広告を配信
- 潜在顧客をターゲットとして広告を配信する
- BLADEのRTBレスポンス数
- 2013/1現在、25億件/日
BLADEの内部
- 処理の流れ
- 広告リストアップ
- 広告データ、リターゲティング、オーディエンスターゲティングデータ、demographicsデータ それぞれ数億件
- 配信不可広告のフィルタ: 競合社の広告など
- 入札額の導出
- frequencyデータ: 同じ広告を何度も見ると興味が下がっていくため
- 入札広告の決定
- 広告リストアップ
- 5msへの取り組み
- データ参照がボトルネックになりがち
- 一般Webアプリと同じ
- アプリケーションまわりのデータ参照の工夫
- KVS(Kyoto Tycoon)
- replication
- cache
- object cache
- データ参照がボトルネックになりがち
- KVS: Kyoto Tycoon
- replicationとローカル参照
- デー糸サイズが大きい(1k〜)と通信コストが高くなる
- データ参照するRTBサーバ上にスレーブを立てて通信を減らす
- cache
- 使い分けが大事
- 整理性やリアルタイム性をどの程度担保すべきか
- よく使う方法2つ: 全件キャッシュ、有効期限つきLRU
- 全件キャッシュ: まんべんなくアクセスされる
- 起動時にロード、2分ごとに更新スレッドで全件リロード
- 入札に選ばれたときに最終確認する
- LRU: 頻繁に参照されるもの
- 広告枠ごとのベース入札額
- 一定件数だけcache
- ミスヒット時、マスタから取得、一定確率でcache
- 使い分けが大事
- object cache
- 取得したデータをJavaのObjectにするにも時間がかかる
- Objectになった時点でキャッシュ
まとめ
- まとめ
- RTBってのがあるんだよー
- 業務ロジックの高度化と処理の高速化が両方必要
- Microad BLADEはがんばっています
- もっと話したかったこと
- 少数精鋭: 入札アプリは3名のエンジニア
- なぞな職人たち
- Action!
- 職人魂でエッジの効いたモノづくりをしていきましょう!
- 想い: 動けばいい/無駄なんて気にするな、サーバー足せばいい
- → クールじゃない。伝統職人に笑われちゃう
感想
普段見ているWeb広告がこのような仕組で配信されているとは知りませんでした。時間的制約のある中での処理の工夫が面白かったです。最終確認でアウトならあきらめるというのは、処理数が多いからできる技でもありますね。
ワンクリックデプロイ 〜いつまで手でデプロイしてるんですか〜
- 15-A-7
- スライド
- @ryuzee 吉羽龍太郎 Ryuzee.com
- Microsoft MVP
- アジャイルコーチ
- SCRUM Boot Camp the book
はじめに
- 本当に必要なものがわかるか?
- ブランコの絵
- SIでよく起こる話
- もっとひどいバージョン
- 期待のマネジメントに失敗
- システムの機能の利用割合
- 2000年 Stanish
- まったく使わない機能が45%、ほとんど使わない19、たまに16、よく使う13、いつも使う7
- まったく使わない、ほとんど使わないで64%。これらを作らなかったら3分の1の期間・コストで作れたのでは?
- あなたの開発はムダだらけ?
- トヨタ生産方式
- ムダ: 作りすぎ/手待ち/運搬/加工/在庫/動作/不良をつくる
- 加工のムダの例: 進捗はわかっているのにおえらいさん向けにプレゼンを作る
- コストの見積りは正しいか
- 不確実性コーン
- ウォーターフォールV字モデル
- 時間がかかりすぎて、出来た頃には要求が変化。そもそも要件があっていなかったということが全部できてからわかる
- よく見かける光景
- 設計までは順調→開発・テストで遅れ→受入れ試験でニーズ不一致が判明
- 多くのリスクが後半になって顕在。そのころにはとり返しがつかない
- Agile Manifest
- Kent Beck, Martin Fowlerら
- 顧客満足を最優先し、規値あるソフトウェアを早く継続的に提供する
- マーケットに製品を早期に投入して、投資を回収し、利益に結びつける必要がある
- ドカーンと計画して長い時間かけて作ります、ではない
- MVPとフィードバックループ
- ビジネスの成長とプロダクトの成長
アジャイル開発
- よくある話
- 「てめーもっとちゃんとアプリ作れ」
- 「運用でなんとかすんのがあんたらの仕事だろ」
- 「そんなのどっちでもいいからビジネスのこと考えてよ」
継続的デリバリー
- 継続的デリバリーの原則
- 1. デプロイはくり返し可能であり信頼性がある
- 2. すべてを自動化する
- 3. 難解、苦痛なことを自動化
- 4. すべてをSCMで管理
- 5. 完了は「リリースされたこと」を意味する
- 6. 品質を作りこむ
- 7. すべての人にリリースプロセスに対して責任がある(もっと言うとプロダクトに対して)
- 8. 継続的に改善する
テスト自動化
- テスト自動化
- 問題は早めに解決する
- 早く見つけて早く直す
- デプロイのたびに人手でテストするなんて無理
- テストしてないものを目をつぶってデプロイしてはいけない
- 悪魔のささやき: 設定ファイル1行だけだから平気だよね?
- テストしてないものを目をつぶってデプロイしてはいけない
- アジャイルテストの4象限
- 自動テストに求められる特性
- repeatable, independent, self validation, easy
- webだと
- controllerのテストを沢出書かなきゃいけないのはfat controllerだから
- Jenkins
- 継続的にテストしていないといつこわれたかわからない
- CIサーバ
- プロジェクト初期からやる
- メトリクス取得や静的解析は初期からじゃないとダメ
- CIアンチパターン
- テストコードと製品コードを同時にコミットしない
- 帰り際にコミットして結果を見ずに帰る
- 何も変更してないのにビルドが落ちたり落ちなかったり
- CIサーバーのメッセージが多すぎる
- 本番環境とステージング環境が大幅に違う
- チェック内容が変わらない、プロセスが変わらない
- などなど
バージョン管理
- バージョン管理
- 設定情報のバージョン管理
- バージョン管理は開発者のしつけ
- どの断面でも再現可能か(昨日、1週間前、先月のバージョンに戻せるか)
- ソースだけではないDBスキーマも
環境構築の自動化
デプロイ自動化
- デプロイ自動化
- 以上ができてはじめて可能になる
- 手でWinScpとかありえない
- ゼロデプロイ
- プロジェクト最初に、デプロイを自動化する
- デプロイが自動化しやすいプロダクトの作り方がある
- 気をつけること
- デプロイが失敗した場合にロールバックできるようにする
- デプロイが途中で失敗した場合、その先を手動でやってはいけない
- Capistrano
- よくあるデプロイ方法
- 難しいところ
- DBの不可逆な変更を避けるようにアプリを作り込んだほうが良い場合が多い
- 1回冗長にしておいて、うまくいったら消す
- いったんトリガを張っておいて後で消す
- ビルドパイプライン
- テスト完了してからリリースするまで何日かかる?
- 障害時に1日でリリースできるのに、障害でないときにできないのは、プロセスに組織的なムダがあります
- ワンクリックでデプロイできたとしても、リリースの意志決定が遅かったら意味がない
- → 組織のアジリティーを高める
- 変化しないとゆるやかに死ぬ
- 自分たちで変えていく。できることは沢山あるはず
- すぐできるものではない
- DevOps
- 開発と運用が協力しあって、継続的にプロダクトを顧客に届けつづける
まとめ
- まとめ
- ビジネスのために継続的に
- アジャイルなやり方
- テストの自動化
- 常に出荷可能
- デプロイや環境構築も自動化
- 改善をずっと続ける
感想
「ワンクリックデプロイ」というタイトルから、chefやcapistranoの話かと思って聞きにきました。しかしアジャイルやスクラムの話が長々と続き、これはどうしたことだと思っていました。話が最後の方まで来てようやく、「ワンクリックデプロイ」というのはアジャイル開発の一部であることを理解しました。ばーんと導入してばーんとできるようになるものでなく、プロセスの改善を続けてだんだん近づいていくゴール(サブゴール)だということがわかっていなかったんですね。一段上の視点を得られた貴重なお話でした。
セキュリティ要求仕様モデルプランで日本は変わるか？
- 15-C-8
- @takesako
- @ockeghem 'or'1'='1'--@tokumaru.org
- うっかりSQLインジェクション脆弱性があると困るアドレス、アカウント登録には使っていない。こわくて使えないw
- orをandにすればというマジレスをもらっている
- 百瀬昌幸さん
- セキュリティ要求仕様モデルプラン知ってる人? → 6人くらい
- 時々オフレコマークがつきますよ
- 地方公共団体における〜〜モデルプラン、略して「モデルプラン」
- LASDEC (財)地方自治情報センター
モデルプランの紹介
- 百瀬さん
- スライド
- モデルプランの中身
- セキュリティー仕様選定基準イメージ
- A 実際に攻撃に使われている手法
- B 現売点で悪用可能で、将来攻撃に悪用される可能性のある手法
- その他に未知の脆弱性などがある
- 対策が可能でコストがかかりすぎないものを選んでモデルプランとした
- セキュリティー要件の提示方法: それぞれ長短あり
- 脅威を明示
- 名前を明示
- 実装方法を指定
- 検査方法を明示
- 実装方法を指定するのがわかりやすい
- 脆弱性が発見されたら直してください、など
- モデルプラン検討経緯
- 救援を送る → ムリ、首長を啓蒙する → どこから話していいか
- 根本的な対策が必要 → そもそも脆弱性のあるソフトを作らなければいい
- 容易に改修できるようにする
- 今後、地方公共団体のセキュリティーレベル向上に必要な施策
- 事後対策 + 事前対策(new) = セキュリティーレベル向上
- 地方団体が1800近くある。お金ののあるとこもないところも
- ユーザー企業・団体・国も巻き込みたい。ベンダーさんにもあらかじめ対応しておいてもらいたい
- 「いいモデルプランです、パクっていいですか」「どんどんパクってください」
- モデルプランのポイント
- 「セキュリティ保証期間」という期間を設け、「脆弱性リスト」で示したものに限定して対処を求めている
- 「セキュリティ保証期間」==5年間(稼動予定期間)とする
- 瑕疵担保期間とは別
- 追加費用なしで直せ≠無償で
- 追加費用なしでの効用
- リスクの見積もりを提案者(ベンター)に委ねる
- 「自ら開発したソフトで事後に脆弱性が発覚するリスクを見込んで保守費用に対応費用をあらかじめのせといてください」
- 地方公共団体の調達==ほとんど入札、となれば広がっていくはず
- モデルプランの採用が進むと…
- 対応可能なベンダーが強くなり、脆弱性のある製品が減る
- アンケート: モデルプランを利用したいと思いますか
- まとめ
- 期間と内容を限定して、万一出たら直してくださいね、となっている
- 熱心なベンダーにとっては優位な仕様
- 地方公共団体向けだけど、もっと活用の幅を広げたい
モデルプランの主要論点
- 徳丸さん
- 大変な仕事だった。高木浩光さんにウンと言わせるのが大変だった
- 論点1: 脆弱性名の列記ではあいまい
- 「○○脆弱性がないこと」では契約にならないのでは? など
- 論点3: セキュリティー保証期間
- OS、ミドルウエアも5年なら5年保証しないといけない(サポートライフサイクル)
- セキュリティー保証期間、これは瑕疵担保ではないのか → 別のもの
- 論点4: 地方公共団体職員の検収能力に関する課題
- 職員さんはまじめだが技術力はない。検収できるのか?
- 受注者に「セキュリティ検査報告書」の提出を求める。入礼価格の中でやってもらう
- 発注者にとってのモデルプラン
- 発注者とベンターの責任分担を明確にする
- 未知の問題については責任を問えないので、発注側の責任
- 提案者にとっての意義
- セキュリティ施策について、何をどこまでやればよいかを明示
- 対応範囲を明確にする
- 提案時に責任範囲を明確にすることにより、真面目なベンダーさんが得をするように(安かろう悪かろうが勝たないように)
- 脆弱性が指摘されたとき実際に改修しましたか?
- 1: 発注者の費用で直した 15%
- 2: 受注者の費用で直した 55%
- 3: そう方の負担で直した 30%
- 4: 直さなかった 0%
- どうせ受注者の持ち出しになるなら、そう明記しておくほうがいい
- サポートライフサイクルポリシー
Q&A
- 会場: 自治体サイトに脆弱性が発見された場合、ベンダーの立場として費用をかけて改修しましょうと言ってもなかなか難しい。enforceする仕組はあるのか
- 百: お金がなければできない。結局お金の問題になってしまう。今後はあらかじめ用意しておきましょうという話になる
- 徳: 脆弱性診断をしているとPHP4だから上げましょう → 「RedHatのサポートが切れているので上げられません」…あっ、PHPって無料じゃなかったんだ、と思った瞬間だった
- 竹: サポート期間が5年ということでRHEL6を選択するような力がかかると
- 竹: モデルプランはPHP以外にも適用可能?
- 徳: JavaもOKです。ただし、サポートサイクル的にJava6が終わっても平気かどうかは検討が必要。どうしてもJava6でないと困るという場合、重要事項説明を書いてもらって別途費用がかかる旨書けばいい
- 竹: 最近のJavaの脆弱性はクライアントアプレット側のものが多いが、サーバー側の修正も必要でしょうか
- 徳: 大丈夫という判断ができるなら、当てなくてもいい
- 竹: Javaの脆弱性で困ったことはあるか?
- 竹: Javaの場合はbyte codeの後方互換性は守られているので、気にしない人が多いのかな、と思っていたんだけど
- 徳: そこまで大胆に上げる人はいないのでは?
- 会場: オラクルから非互換リストも出ているので、テストなしでアップデートはありえない。unit testで確認するということはある
- 百: クライアントサイドの問題が取りざたされている。省庁によってはJavaの古いバージョンを使い続けるのは許さないというのが強く打ち出されてきている。そういう号令は省庁では絶対の話。クライアント側はむしろ強く求められていく
- 竹: Javaアプリを使っている地方団体アプリはあるのでしょうか
- 百: いやーあるんですよー、IE6でしか動かないとかー。対応するためにベンダー内では、専用のパソコンを別ネットに用意して検証しているようだ
- 徳: 「5年しか使えないの?」という声もあった。発注したからには未来永劫使いたい、と。5年経ったらチェックして、使えますねとなったら使い続けるなどを推奨する
- 会場: セキュリティーの範囲として、スマホ、タブレットに対応というと、Webと環境が違うと思う。適用できるのか
- 竹: JSSECから「アンドロイドアプリのセキュア設計・セキュアコーディングガイド」が出ているのでチェックするのをおすすめ
- 会場: リスク評価して応札価値に上乗せしろ、とかそんなことは実現可能なのか
- 百: 脆弱性が出たのに対応してくれないような業者は淘汰されていくと考えている。チェックできるような書類も提出してもらうことになっているので、後から何かあったときにもさかのぼってチェックできる。このモデルプランで万全ということではなく、うまくいかないということになればまた第2版、第3版と改訂していけばいいと考えている
- 会場: Javaのアップデートするとき、旧バージョンをアンインストールしないと、アプレットがバージョンを指定することができてしまう
- 百: 旧バージョンを消してね、という通知はしている
- 会場: T市のように海外のサービスに自治体サイトを移した場合、海外サービスのセキュリティー評価をするようなこともあるのか?
