Speaker Deck で最高の URL を生成する技術

Speaker Deck の仕様

Speaker Deck に発表資料を公開するとき「タイトルから URL が生成される仕組み」になっている.タイトルが全て英語なら問題はないけど,タイトルに日本語が含まれる場合は「中国語のようなローマ字」になってしまうという裏仕様があり(以下に例を載せた),今まで「内容は素晴らしいのに URL が残念すぎる資料 💦」を多く見てきた.知っている人は知っている仕様だと思うけど,まだまだ普及していなさそうなので,今回ブログに書くことにした.

プロジェクトをリードする技術
puroziekutoworidosuruji-shu

最高の URL を生成する技術

今回「Speaker Deck で最高の URL を生成する技術」を紹介したいと思う.と言っても本当に簡単なことで,以下のように「スラッシュ区切りで英語タイトルを追加する」だけ!最高すぎる!

日本語タイトル / 英語タイトル

サンプルとして今まで公開してきた資料を例として載せておこうと思う.なお,1番最後のサンプルからわかる通り ! は無視されることも知っておくと良いと思う.

タイトル 生成 URL
プロジェクトをリードする技術 / Project Leading is Skill https://speakerdeck.com/kakakakakku/project-leading-is-skill
Mackerel で ECS をどこまでモニタリングできるのか / Monitoring ECS with Mackerel https://speakerdeck.com/kakakakakku/monitoring-ecs-with-mackerel
アウトプット駆動学習を習慣化する / Output Driven Study https://speakerdeck.com/kakakakakku/output-driven-study
ブログを書く技術 / Blog is My Life https://speakerdeck.com/kakakakakku/blog-is-my-life
日本で働きながら海外名門大学で学べる!そう Coursera ならね! / Coursera is Awesome ! https://speakerdeck.com/kakakakakku/coursera-is-awesome

まとめ

最高の発表資料を「最高の URL」で Speaker Deck に公開しよう!

関連記事

Keynote で「最高の発表資料」を作る方法は以下の記事にまとめているので,合わせて見てもらえると!

kakakakakku.hatenablog.com

Akamai と Fastly の事例を聞くために「CDN Study」に参加した

参加してからもう3週間も過ぎてしまったけど,4月に参加した「CDN Study」の感想をまとめておこうと思う.

http2study.connpass.com

オープニング

  • 最適化の原則
    • なるべく近く
    • なるべく少なく
    • なるべく小さく
  • CDN の存在感と世界観がどんどん広がっている

speakerdeck.com

Past, Present and Futures of CDN / Akamai Technologies

  • Akamai は 1700 を超えるエッジ(POP と呼ぶ)を持っている
    • 競合と比べても圧倒的に差がある
    • ただし「多ければ良い」という単純な話ではない
  • どうやって「最適なエッジ」に誘導するのか?
  • CDN は Contents Delivery Network ではなく Cloud Delivery Network と言える
  • EdgeWorkers : エッジで動作する JavaScript を開発している
  • 「キャッシュ」をチューニングの手法としてではなく,初期設計から検討する
    • TTL などは要件を整理しておく
    • ステートレスなアプリケーションを目指す
  • Cacheability
    • キャッシュの運用を前提とした,アプリケーションの記述手法があると良さそう
    • Swagger のような?

Akamai と言えばエンタープライズなイメージが勝手にあり,今回のようなカジュアルな勉強会で発表を聞くことがなかったけど,Contents Delivery Network(もしくは Cloud Delivery Network)企業として,非常に技術的なチャレンジをされているなと感じた.エッジの数がここまで多いのは知らなかったし,「最適なエッジ」に誘導するための特許を持っているのも知らなかった.このあたり,技術的に異常に深みがありそう.最後に話があった Cacheability モデリングの話は,今後に対する問題提起のような形になっていて良かった.キャッシュは用途を間違えると逆に制約になってしまうこともあり,ちゃんと設計して,活用する意識を改めて持つことができた.

speakerdeck.com

CDN Study in http2study / Akamai Technologies

  • 標準化
    • IETF (Internet Engineering Task Force) など,ワーキンググループにメンバーを派遣している
    • HTTP/2
    • QUIC
    • TLS 1.3
  • HTTP/2 はデフォルトで有効になっている
    • Server Push も使える
  • 2018年6月から QUIC でストリーミング配信をおこなえるようになる
    • 例えば,HLS 動画ファイルの取得が高速になったりする
  • TSL 1.3
    • Draft 21 / Draft 23 に対応した OpenSSL なら TSL 1.3 で接続できる

www.slideshare.net

Fastly のプログラマから見た CDN

  • Fastly の POP 一覧
  • CDN には2種類のモデルがある
    • コンビニモデル : Akamai
      • すぐ近くに POP がある
      • よって,レイテンシが下がる
    • スーパーマーケットモデル : Fastly
      • 巨大な POP がある
      • よって,キャッシュヒット率が高くなる
    • モデルの解説は以下のブログにある
  • ルータレス・ルーティング
    • 32台のキャッシュサーバが,それぞれルータも兼ねている
  • ステートレス・ロードバランス
    • LB を置かず,IP と PORT をハッシュ化して,キャッシュサーバを決定する仕組み
  • CDN 専用の独自ファイルシステムを開発している
  • Fastly を CDN ではなく「分散 KVS」として考えることができる
    • VCL : Varnish Configuration Language
    • インスタント・パージ
      • サロゲートキーを指定して,特定のキーが付いた複数のキャッシュを一括でパージできる
  • 日経新聞社の事例もある
  • CDN に関係するプロトコル拡張
    • DNS over HTTPS
      • DNS に問い合わせたことを記録させず,セキュアに通信ができる
    • Early Hints
    • Server Timing
    • Variants
  • QUIC を TCP/2 を言ってはダメ(ワーキンググループ的に)

コンビニモデルとスーパーマーケットモデルの話は知らなかった!面白すぎる.また,ルーティングとロードバランスの話など,ソフトウェアとして課題解決をされている印象があり,Akamai と違う規模,違う戦略なんだなという点も知れて良かった.最後にまとめたプロトコル拡張の話は詳しく理解できていないため,調べることを自分の宿題にしたいと思う.

speakerdeck.com

まとめ

  • 抽選倍率2倍の「CDN Study」に参加した
  • 今まで聞いたことがなかった Akamai と Fastly の発表を聞けて良かった
  • TLS 1.3 / QUIC など,プロトコルの話は理解が不足していることを痛感した
  • アプリケーションと Cacheability の話は今後の設計に活かしたいと思う

Google Analytics / Google Tag Manager 初学者にピッタリな「わかばちゃんと学ぶ Google アナリティクス」を読んだ

3月末に発売された「わかばちゃんと学ぶ Google アナリティクス」を読んだ.著者の湊川さん,献本ありがとうございます!

わかばちゃんと学ぶ Googleアナリティクス〈アクセス解析・Webマーケティング入門〉

わかばちゃんと学ぶ Googleアナリティクス〈アクセス解析・Webマーケティング入門〉

本書で学べるのは Google から提供されている以下のサービス群で,このあたりに興味のある初学者にピッタリな内容になっている.個人的には以下のサービス群は仕事でも個人でも使っていて,そこそこ理解のある中級者だと思うので,中級者目線での書評をまとめたいと思う.

  • Google Analytics
  • Google Tag Manager
  • Google Search Console
  • Google AdWords
  • Google Data Studio

コンバージョン計算式

Chapter 1 で「コンバージョン計算式」の話が出てくる.「コンバージョン = 訪問数 x コンバージョンレート」で,コンバージョンレートは業界の平均値を目指しつつ,訪問数を伸ばしていくようなストーリーになっていた.これは Google Analytics などのサービスを使う前に知っておくべき知識なので,ちゃんと書かれているのが素晴らしいなと思った.仕事でも「どうにかして,コンバージョンレートを改善しよう!」という施策を進めることがあるけど,柔軟に考えると,実は訪問数を伸ばせば良かったりする場面も多くある.

すぐに試せる Google Merchandise Store

Google Analytics を試す環境として,Google Merchandise Store の Google Analytics が公開されていることを知った.コンバージョン(目標)など,どのように設定をすれば良いかという「お手本」にすることができるため,気になったときに見れるように設定しておくのが良いと思う.これは知らなかった!

support.google.com

f:id:kakku22:20180430144429p:plain

フィルタ

Chapter 2 で Google Analytics のフィルタ機能が紹介されているのも良かった.会社の IP を除外するテクニックはあまり知られていないような気がしていて,実践的な内容になっていた.

セッションの定義

Google Analytics を使っているなら「セッション」の概念は理解していると思うけど,「セッションタイムアウト = 30 min 固定」という理解をしている人が多いように思う.確かにデフォルト値はそうなっているけど,ここはサービスの特性によって変更できるので,ここも実践的なテクニックが紹介されていて良かった.

f:id:kakku22:20180430144411p:plain

Google Search Console 連携

ブログを運営していると,どのような検索キーワードで流入があるかを把握することが重要なので,Google Search Console は定期的に確認している.Google Analytics だけを使っていると (not provided) が多く困るため,初学者でも Google Search Console を使えるように書かれていて良かった.なお,僕はブログを運営していて,以下のメトリクスを定期的に確認している.

  • Google Analytics
    • ページ/セッション
    • ページビュー数
    • 平均ページ滞在時間
    • 直帰率
    • 新規とリピーター
  • Google Search Console BETA (最近はリニューアル版を使っている)
    • クエリ
    • 平均 CTR
    • 平均掲載順位

f:id:kakku22:20180430144354p:plain

少し気になったこと

本書では,Google Analytics などの操作を説明するために,Chrome のキャプチャが多く載っていて,初学者でも迷うことなく理解できるようになっている.ただし,一部の Chrome のキャプチャで「macOS のメニューバー」と「Chrome のツールバー」まで見えているため,導入されている Chrome 拡張もわかってしまった.小さなことかもしれないけど,このあたりは全てのキャプチャで統一しておくと良さそう.

Google Analytics をマスターするなら

本書で Google Analytics に入門して,もっと活用しようと思ったら「できる逆引き Google アナリティクス」を読むのが1番良いと思う.とにかく詳細に解説されていて,Google Analytics ってこんなに機能あるのか!と驚かされると思う.

ネットマーケティング検定

Google Analytics とは直接関係ないけど,マーケティング関連の認定資格(検定)があり,そこまで難しくはなく,僕は2015年に取得している.参考までに紹介しておく.マーケティング関連の仕事をしているなら取得しておいても良さそう.

www.sikaku.gr.jp

kakakakakku.hatenablog.com

まとめ

  • 「わかばちゃんと学ぶ Google アナリティクス」 を読んだ
  • Google Analytics / Google Tag Manager 初学者にピッタリな内容になっていた
  • フィルタ,セッションの定義など,実践的なテクニックも紹介されていた

関連記事

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

プロジェクトをリードする技術

今日,社内勉強会で話す機会があり,過去1年間を振り返りつつ「プロジェクトをリードする技術」というタイトルにした.今回は参加者がエンジニアだけじゃなく,ビジネスチームのメンバーもいたため,できる限り,技術的な用語を使わないようにした.質疑応答とディスカッションもあり,1時間非常にワクワクした時間だった.

関連する領域

僕がプロジェクトをリードするときに意識しているのは,スクラムなど特定のプラクティスに依存しすぎないことで,チームの特性によって,関連する様々な領域からプラクティスを集めている.ザッと挙げるだけでも,こんなにたくさんある.

  • チームビルディング
  • ファシリテーション
  • マネージメント 3.0
  • アジャイル (スクラム / カンバン / XP)
  • 組織論
  • 育成
  • 心理学
  • メンタリング
  • プロジェクトマネジメント

資料

過去1年間に取り組んだことを全て詰め込んだ!プレイングマネージャーとして頑張ってきた「集大成」とも言える.プロジェクトを任された新任リーダーにオススメ!

speakerdeck.com

関連する資料

「XP 祭り 2017」や「July Tech Festa 2017」で登壇した内容も一部含めている.

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

関連する書評

オススメ本を多く資料に含めた.本から学んだことを実践すると1番学びになる.

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

「Japan Container Days v18.04」に参加して1日中コンテナのことを考えていた

今日は「Japan Container Days v18.04」に参加してきた.正直「Container Days」と言うよりも「Kubernetes Days」って感じだったけど,1日ずっとコンテナのことばかりを考えていた.発表テーマも多岐にわたっていて,バランスが非常に良かったと思う.僕が参加したセッションをまとめておく.

containerdays.jp

サイバーエージェントにおけるプライベートコンテナ基盤 AKE を支える技術

  • ake client を使ってクラスタを起動できる
    • ake client の裏は OpenStack Heat を使っている
  • Kubernetes にパッチを当てているため,ビルドから始める
  • Kubernetes と Swarm をサポートしている
  • Datadog / Elastic Stack なども連携できる
  • 既存のエコシステムは採用しなかった
    • OpenStack Magnum
    • Rancher
    • Tectonic

3年前まで所属してたアドテクスタジオからの発表だった.「おうち Kubernetes」の事例などは知っていたけど,AKE の詳細解説は今まで聞いたことがなかった.実装は大変そうだけど,既にプロダクションでも稼働してるとのことで,すごいなぁー!

developers.cyberagent.co.jp

speakerdeck.com

マイクロサービスアプリケーションとしての機械学習

  • メルカリの画像認識機能
    • 出品時に写真を撮ると,名前,カテゴリー,色などを自動推定する
  • 機械学習エンジニア側で Dockerfile を用意すれば,残りは SRE で構築してもらうことができた
    • Web Server / Queue / Worker / 機械学習モデルなど
  • 継続的デリバリーは Spinnaker を使っている
    • GUI で直感的に使える
  • 機械学習モデルのリリースは,最初は「意図的に手動で」運用していた
    • 多様である機会学習モデルの運用がどういうものなのかを把握するため
    • 汎用性の不足もある
  • Persistent Volumes でデータを共通化すれば,機械学習モデルの Blue/Green Deployment が実現できる

話を聞いて感じたのは「やはりメルカリ強いなぁー」ということだった.アカデミック出身の機械学習エンジニアがいたり,フルスタックなアーキテクチャ(資料参照)を1週間で作ってしまう SRE がいたり.また「意図的に手動で」運用をして,様子を見るというフローも良かった.実際に「画像認識機能」は使ったことがあるので,この機能の裏側はこんな感じだったのかーと知れて良かった.

speakerdeck.com

Yahoo! JAPAN の Kubernetes-as-a-Service で加速するアプリケーション開発

  • Yahoo! ズバトク on Kubernetes
  • 今までの課題
    • 簡単にスケールアウトできなかった
    • リリースの自動化ができていなかった
  • そこで Kubernetes を導入した
    • Concourse CI を使ってデプロイをしている
    • デプロイ時間も早くなった
    • OpenStack のノードがダウンしても,セルフヒーリングでポッドを再配置できる
  • アプリケーションも合わせて変えないと Kubernetes の恩恵を受けられないので,マイクロサービスに書き換えた
  • Z Lab では Yahoo! Japan の Kubernetes-as-a-Service を開発している
  • Kubernetes-as-a-Service on Kubernetes

Z Lab って聞いたことないなと思ったら,Yahoo! で使う基盤を作る 100% 子会社だった.Kubernetes-as-a-Service on Kubernetes というパワーワードも出ていたけど,他社と似ていて,OpenStack に Kubernetes クラスタを立てて共通基盤として提供するような感じだった.さらに Kubernetes を「分散システム基盤」という側面で考えているのは勉強になった.

www.slideshare.net

Kubernetes のセキュリティベストプラクティス

  • フロントエンドのポッドから /var/run/secrets/kubernetes.io/serviceaccount/token などの秘匿情報が漏れてしまう場合
    • リクエストヘッダーに Bearer Authentication を指定して接続されてしまう可能性がある
  • RBAC (Role-Based Access Control) を使う
  • API Server Firewall
    • gcloud container cluster--master-authorized-networks オプションを使う
  • Kubernetes Network Policies
    • もしパスワードが取れたとしても,Web ポッドから,Redis ポッドに直接繋がらないようにできる
    • 必要なポッド間だけを通す
  • securityContext に設定する項目
    • runAsUser
      • root ユーザー以外でプロセスを実行する
    • readOnlyRootFilesystem
      • ルートファイルシステムを読み取り専用にする
    • allowPrivilegeEscalation
      • 特権を取らせないようにする
  • Seccomp で不要な syscall を呼べないようにする
  • Istio など,サービスメッシュを使って,ポッド間のアクセスを制御することもできる

Kubernetes を運用するときに必要になるセキュリティ関連のパラメータを聞くことができた.まだ Kubernetes クラスタは運用していないけど,Network Policies など,注意するべきパラメータを知ることができたので,いざ運用するときに活かせそう.最後にサービスメッシュの話も少し出ていた.

speakerdeck.com

Horizontal Pod Autoscalers

  • 規模感
    • マイクロサービス 124+
    • kubernetes ノード 80+
    • コンテナ 3000+
  • Horizontal Pod Autoscaler (HPA)
  • 要件
    • 突然のスパイクに勝てる
    • 秒単位でスケールできること
    • 新規サービスも反映できる共通化された設定
      • Distributed Monolith にならないように
  • モニタリング
    • k8s-prometheus-adapter
    • Prometheus でメトリクスを取得する
    • nginx_exporter をサイドカーパターンで稼働させれば,メトリクスは簡単に取れる

Kubernetes でポッドをオートスケールしながら,メトリクスを取得する話だった.Wantedly のマイクロサービスはどんどん増えている気がする.既に120個超え!実際に負荷をかけたときのメトリクスを紹介するスライドに hey というコマンドが使われていた.Go で書かれた負荷ツールだと Vegeta を普段使っていて,hey は知らなかった.

github.com

speakerdeck.com

Container Networking Deep Dive

発表の最後に「Kubernetes を運用するなら,ネットワークも理解しましょう!」と言われていて「うっ確かに」という感じだった.ネットワークレイヤーの話で難しかったけど,ポッド同士がどのように疎通しているのか,図解がわかりやすくて良かった.

www.slideshare.net

Spinnaker を利用した Kubernetes への継続的デリバリ

  • Kubernetes は CI / CD の実現が課題になる
  • Spinnaker
    • Spinnaker
    • Netflix 社が開発している OSS
    • マルチクラウドに対応している
    • Kubernetes にデプロイができる
    • GUI で簡単にパイプランを作ることができる
  • デプロイ方法
    • Red/Black Deploy ( = Blue/Green )
      • Netflix では Red/Black と呼んでいて,意味は一緒
    • Rolling Red/Black Deploy
    • Canary Deploy
  • CI は Jenkins or Travis CI と連携できる
    • 逆にそれ以外は連携できない
  • Chaos Monkey Integration

メルカリの事例などで,最近よく聞くようになった Spinnaker の話だった.初心者セッションだったので,基礎的なところから聞くことができて,良かった.GUI 中心で Kubernetes の継続的デリバリーができるのは非常に便利だけど,それだと「Spinnaker おじさん」が出そうだから,どこまで Infrastructure as Code ができるのか,気になるところ.Netflix のデプロイ事例は以下の記事に載っている.

medium.com

speakerdeck.com

Kubernetes のない世界 すべてがサーバーレスになる

今日1番面白かったセッションだった.雰囲気としては「@yoshidashingo と @toricls のトークショー✨」という感じだったけど,コンテナ,Kubernetes,サーバレス,オンプレなど,注目のキーワードを軸に様々な視点から議論を繰り広げていた.まさに「ご意見番」って感じ.特に「Less Ops, More Code」というスローガンは良かった.Fargate など,コンテナを用意すればあとは良しなにやってくれる系のサービスが普及するのは素晴らしいと思っているし,もし EKS Fargate が出れば,Kubernetes をほとんど意識せずに使えるような未来が来そう.

www.slideshare.net

まとめ

  • Japan Container Days v18.04 に参加してきた
  • 各社 Kubernetes 最高!という感じだけど,セキュリティ,モニタリング,ログ,デプロイなど,運用面で工夫されていた
  • 「Less Ops, More Code」を目指して Kubernetes を意識しないような未来の話を聞けたのも良かった
  • 最後少し CNCF の話を聞けたのも良かった
  • あまりにも Kubernetes に偏ってたので,ECS や Fargate の話があればさらに良かったかなとは思う

関連記事

これから Kubernetes を学ぶなら,ワークショップ資料「aws-workshop-for-kubernetes」がオススメ!

kakakakakku.hatenablog.com