Upgrade to Pro — share decks privately, control downloads, hide ads and more …

1時間に詰め込むはてなインターン2022 技育祭2022秋 / Hatena Intern i...

Hatena
October 18, 2022

1時間に詰め込むはてなインターン2022 技育祭2022秋 / Hatena Intern in 1 Hour Geeksai 2022 Autumn

技育祭2022秋 https://talent.supporterz.jp/geeksai/2022autumn/ での発表です

Hatena

October 18, 2022
Tweet

More Decks by Hatena

Other Decks in Technology

Transcript

  1. 株式会社はてな • 2001年 創業、2016年 東証マザーズ上場 • 従業員 約200名 ◦ うちエンジニア約80名

    • ミッション ◦ 「『知る』『つながる』『表現する』で新しい体験を 提供し、人の生活を豊かにする」 5
  2. インターネットと地続きな文化 • ハンドル ◦ ハンドルネーム(はてなID)で識別 ◦ 社外のIDをそのまま社内に持ち込むパターンが多い • オープン ◦

    グループウェア・社内日記でテキストによるコミュニケーション ◦ 可能ならばインターネットにも • ドッグフーディング ◦ 自分たちで作ったサービスを自分たちでも使う 6
  3. • 開発・運用・運営の技術を提供する ◦ サービスの受託・共同開発 ◦ SaaS の提供 • Mackerel ◦

    はてなのノウハウをベースにした監視サービス • マンガ・ノベル・ゲーム ◦ ジャンプ+・コミックDAYS・カクヨム ◦ 任天堂株式会社との共同案件 テクノロジーソリューション 10
  4. CTOの仕事 • ソフトウェアに依って立つ企業としての能力開発 • はてなにおいては: エンジニア横断職種組織の長 • 各チームがそれぞれのスコープで課題に取り組む中で ◦ 何を共通化し、何を自律させるか?

    ▪ 社内共通基盤やノウハウ共有の仕組み ◦ 中期的なスコープで乗り越えるべき技術的な課題は? ▪ コンテナ化の号令やセキュリティ強化の体制 ◦ はてなのエンジニアはどうあるべき? どうやってそうさせる? ▪ 育成や評価・ヒューマンマネジメント体制の設計 11
  5. 12

  6. 10年後の自分をつくる • インターン生たちはいま ◦ 多くはソフトウェアエンジニア ◦ プロダクトマネージャ、CTO、研究者もいる • 技術の変遷 ◦

    2010s: DevOps、GitHub、AWS、JavaScript ▪ (-) LAMP、jQuery、CoffeeScript… ▪ (+) コンテナ、サーバレス、マイクロサービス、React、TypeScript 13
  7. インターンが提供するもの • 知識 ◦ 深く狭く、よりは広く浅く。インデックスを張ってもらう ◦ 表層的なものだけでなく理論や背景も加えて ▪ 技術については、今後も生き残っていく蓋然性の高いものを •

    経験 ◦ インターンが提供できる最大のもの ◦ 可能な限り外部への提供を目指し、外部フィードバックを得る ▪ デプロイ可能なチームであればデプロイまで 15
  8. 前半課程講義 • Web API • インフラ • コンテナ • マイクロサービス

    • RDBMS • フロントエンド • Kubernetes • デザイン 17
  9. 前半課程講義 • Web API • インフラ • コンテナ • マイクロサービス

    • RDBMS • フロントエンド • Kubernetes • デザイン 18
  10. Docker を使う • docker pull <image> # 公開されているイメージをダウンロード # イメージ

    = アプリケーション + 依存 ▪ mysql:8, redis:7, debian:10, … • docker run <image> <command> … # イメージを立ち上げてコマンドを実行 • docker stop <container> # 稼働中のコンテナを停止 21
  11. 自分のイメージを作る 22 • docker build <path> ◦ Dockerfile の指示をもとにイメージを作成 FROM

    golang:1.19 WORKDIR /app COPY . . RUN go mod download RUN go build -o app ./cmd/app ENTRYPOINT ["./app"]
  12. コンテナに至る歴史 • 物理サーバ ◦ 1つのOS内で複数プロセスが稼働 ◦ 増減に物理的な作業が必要 • 仮想化 ◦

    物理マシン上にゲストOSを複数稼働 ◦ リソースの融通が柔軟に ◦ アプリケーションそれぞれにゲストOSが必要 ▪ これがオーバーヘッドではあった 25
  13. Docker (2013) • dotCloud社(当時)がOSSとして公開 ◦ オーバーヘッド低くプロセスを隔離 = コンテナ ◦ Dockerfile

    による再現性のある環境構築 • 開発用から始まり、CI、本番にも • ちなみにコンテナ技術は jails, LXC など以前からあった ◦ Docker の開発者体験のよさが奏功した形 26
  14. “脱ペット化” from インフラ講義 • 物理サーバー ◦ 名前: aoyama, inunaki, …

    ◦ どれだけ長く安定して稼働させるかが重要。大切にメンテナンスする • 仮想サーバー ◦ 名前: blog-app-03, bookmark-db-02, … ◦ うまく動かなければ作り直す • コンテナ ◦ 名前: antenna-app-deployment-bc697497b-66qx9, … ◦ 集合として期待した状態になるように維持・収束される ▪ eg. Kuberenetes 27
  15. コンテナの使い所 (本番) • 各種クラウドプラットフォームがコンテナを デフォルトでサポート ◦ Amazon ECS, Google App

    Engine, … ◦ 「コンテナ」のインタフェースが決まっているので、可搬性がある • サーバの負荷など必要に応じてコンテナを増減 ◦ cf. マシン調達 28
  16. コンテナの使い所 (開発) • ローカル開発に必要なミドルウェアを起動 • Dev Container でチームで共通の開発環境を用意 ◦ インターンでは

    GitHub Codespaces を使うところも • コンテナをデプロイすれば、手元と本番の環境を一致させられる • ポートフォリオとしてのコードが Docker で立ち上がったら親切 29
  17. 32 1. HTTP • URL の先頭にでてくるアレ 👉 http://… • HTTP

    = HyperText Transfer Protocol • ウェブを支えるプロトコル • Web API の基礎を押さえていきましょう
  18. 33 HTTPの歴史 − 1991 HTTP/0.9 − 1996 HTTP/1.0 − 1997

    HTTP/1.1 − 2009 GoogleがSPDYを発表 − 2013 GoogleがQUICを発表 − 2015 SPDYを元にしたHTTP/2の標準化 − 2018 HTTP-over-QUICをHTTP/3に改名 − 2021 QUICの標準化 − 2022/6/6 HTTP/3の標準化
  19. netcat で息吹を感じる 󰳕 % nc hatenablog.com 80 GET / HTTP/1.1

    [改行] Host: hatenablog.com [改行] [改行] 34
  20. 実行例 % nc hatenablog.com 80 GET / HTTP/1.1 [改行] Host:

    hatenablog.com [改行] [改行] HTTP/1.1 301 Moved Permanently Content-Type: text/html Location: https://hatenablog.com/ <html> ... 35
  21. HTTP のセマンティクス > GET / HTTP/1.1 # Method, Target, Version

    > Host: hatenablog.com # Header Field < HTTP/1.1 301 Moved Permanently # Version, Status, Reason < Content-Type: text/html # Header Field < Location: https://hatenablog.com/ < < <html> # Content ... 36
  22. HTTP プロトコルの進化 • ウェブアプリケーションの高度化により、 プロトコル自体を改善する需要が高まる ◦ メディアファイルの増加、TLS、… ◦ HTTP/1.1 …

    テキストフォーマット on TCP ◦ HTTP/2 … バイナリフォーマット on TCP ◦ HTTP/3 … バイナリフォーマット on QUIC 37
  23. HTTP/2, HTTP/3 • セマンティクスは1.1と同じ • HTTP/2 ◦ ひとつのTCPコネクションの中に複数のリクエスト・ レスポンスを詰める •

    HTTP/3 ◦ UDP上でTLSを含めた通信を実現 ◦ パケットの順番待ちや暗号化ハンドシェイクを減らす 38
  24. 2. API • Application Programming Interface • プログラムのためのインタフェース ◦ ライブラリ対プログラム、

    サービス対サービス、サービス対ユーザ • 不特定多数向け (LSUD) or 特定少数向け (SSKD) で性格 が変わる ◦ LSUD: Twitter API、GitHub API ◦ SSKD: スマホアプリ向けAPI etc. 39
  25. (i) REST • HTTPの作法にうまく乗った流儀 • URL is リソース ◦ ユーザ、投稿、タスク、…

    • GET/POSTなどのHTTPメソッドを動詞に ◦ リソースの CRUD に対応させる ▪ CRUD = Create/Read/Update/Delete 41
  26. RESTful API: GitHub POST /repos/:owner/:repo/issues/:issue_number/comments # C: コメントの投稿 GET /repos/:owner/:repo/issues/comments/:comment_id

    # R: コメントの取得 PATCH /repos/:owner/:repo/issues/comments/:comment_id # U: コメントの更新 DELETE /repos/:owner/:repo/issues/comments/:comment_id # D: コメントの削除 42 • 説明的なURLでリソースが表現されている • HTTPメソッドも直観的
  27. GitHub RESTful API を使う 󰳕 43 $ gh api -i

    -X GET /user HTTP/2.0 200 OK Access-Control-Allow-Origin: * ... { "login": "motemen", "id": 8465, "avatar_url": "https://avatars.githubusercontent.com/u/8465?v=4", "url": "https://api.github.com/users/motemen", ... "created_at": "2008-04-25T08:35:37Z", "updated_at": "2022-08-22T10:44:05Z" }
  28. REST Pros/Cons • Pros ◦ リソース指向で直接的 ◦ サーバサイドの実装が素直 ▪ 複雑なことをしたければクライアント側で頑張る

    • Cons ◦ クライアント側で頑張る必要がある ▪ タイムラインのユーザ情報をN回取得しにいく…? ◦ クライアントの要件に柔軟な対応をしづらい ▪ ?with_user=1 みたいなパラメタが無限に増えがち 45
  29. (ii) GraphQL • Meta (Facebook) 製 • クライアント側が欲しいデータを指示する ◦ ラウンドトリップ数を減らす

    ▪ タイムラインの投稿とユーザの情報をまとめて1リクエストに ◦ オーバーフェッチングを減らす ▪ GET api.github.com/users/motemen のキーは32個もある • レスポンスはJSON 46
  30. Schema Definition Language type Query { repository(name: String!, owner: String!):

    Repository } type Repository { issue(number: Int!): Issue } type Issue { author: Actor body: String! title: String! } type Repository { issue(number: Int!): Issue } 47 • サーバもクライアントも 同じSDLをもとにコード を書く or 生成する
  31. GraphQL クエリ 48 query GetFirstIssue { repository(name: "Hatena-Intern-2020", owner: "hatena")

    { issue(number: 1) { author { login } body title } } } • クエリの形が結果のJSONの 形を規定する ◦ クライアントに必要なデー タを過不足なく取得 ◦ ネストしたデータも一発
  32. GitHub GraphQL API 󰳕 % gh api graphql \ -f

    query='query { viewer { name, repositories { totalCount } } }' { "data": { "viewer": { "name": "Hironao OTSUBO", "repositories": { "totalCount": 443 } } } } 49
  33. RPC • = Remote Procedure Call • プログラム中の一部の手続きを 別のプログラムから実行する仕組み •

    IDL (Interface Definition Language) ◦ 呼び出す側と呼び出される側の規格 53
  34. Protocol Buffers syntax = "proto3"; package account; service Account {

    rpc Signup(SignupRequest) returns (SignupReply); } message SignupRequest { string name = 1; string password = 2; } message SignupReply { string token = 1; } 54 • 複数の言語のコード(サーバ・ クライアント)を生成 可能 • 多言語サービス間通信に向いて いる
  35. それぞれの使い所 • GraphQL ◦ 柔軟かつ効率的にデータを取得したい ◦ 例: スマホアプリやWebフロントエンド向けAPI • gRPC

    ◦ ネットワーク越しのシステム間で高スループットを実現したい ◦ 例: 社内マイクロサービス間通信 • REST ◦ 単機能と小規模なケースで、上記の複雑さが割に合わない場合 ◦ 例: フロントエンドリッチでない補助的な機能など 55
  36. 第1章・第2章 完 • 現代ウェブを支える技術について駆け足で見ました ◦ 興味を持った部分は掘り下げてみてください • コンテナ ◦ 常にこれを使うのがオススメ

    • GraphQL ◦ フロントエンドリッチなウェブアプリ・モバイルアプリを作るなら 検討の価値あり ◦ ツールチェインにキャッチアップするコストはかかります 56
  37. 既知の課題から未知へ • 講義パートは既知の課題 ◦ 誰かが解いたことがあり、だいたい何かしら正解がある • 現実世界では課題が未知のものになる ◦ ユーザに届けるもの、検証するもの ◦

    何が正解か (つくるまで|届けるまで) わからない ▪ なんなら変わることだってある ◦ チーム開発を通じて課題を明らかにしていく 58
  38. コードは自分の手を離れてしまう • うごメモはてなの思い出 ◦ 学生の頃からプログラミングが “得意” で、ぼくのかんがえる カッコイイコードを量産していた ◦ はじめてイチから書いたサービスで、愛着もひとしお

    • 年月を経てコードベースも関わる人も増えてくる ◦ だんだんと同僚が自分のコードで苦しんでる姿を見るように ◦ その頃にはチームを異動していて、直接手が出せない • プログラミングからソフトウェア開発へ 64
  39. 70 • Hatena Engineer Seminar #22 会社説明資料に載らないはてな @ 10/26 hatena.connpass.com/event/263147/

    • 2023年のインターンもお楽しみに! ◦ @hatenatech でお知らせします 告知