これからのクラウドネイティブアプリケーションの話をしよう
•
7 likes•4,685 views
2018.12.5 Japan Container Days v18.12 で話した資料です。
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to これからのクラウドネイティブアプリケーションの話をしよう
Similar to これからのクラウドネイティブアプリケーションの話をしよう (20)
More from 真吾 吉田
More from 真吾 吉田 (20)
これからのクラウドネイティブアプリケーションの話をしよう
- 2. 吉田真吾 n バックグラウンド 証券システム基盤開発 p 基盤システム開発、Oracleチューニングなど エバンジェリスト p 講演113回(2013年実績) p AWS設計・構築・移行(2014-2015) n 現在のしごと (株) サイダス 取締役CTO p タレントマネジメントSaaS 開発・運用 (株) セクションナイン 代表取締役社長 p AWS DevOps n 実績等 p AWSウルトラクイズ 初代チャンピオン (2012年) p AWS Samurai 2014 / 2016
- 3. AWSによるサーバーレスアーキテクチャ • サーバーレスアーキテクチャによる 動画共有サイト構築 • オンライン教育動画サイト「A Cloud Guru」で実際に使われている技術や コードをベースにした詳細説明 • AWS Lambda / API Gateway / S3 / CloudFront / Elastic Transcoder / Auth0 / Firebase Realtime Database
- 6. 丹羽一智 n バックグラウンド セガ p携帯電話用ゲーム・サーバー開発/運用 任天堂 p汎用ゲームサーバー開発/運用 pニンテンドー3DS OS/SDK 開発 n 現在のしごと Game Server Services(株) 代表取締役CEO pプレイングマネージャー n 実績等 pAWS Startup architecture of the year2018
- 7. Game Server Services(GS2) • スマートデバイス向けのゲームサーバを1時間あたり 数円から利用できるサービス • 2016年12月14日サービス開始 2018年3月30日 DeNA/KLab/GameWith/大和企業投 資 らから資金調達を実施 • アカウント管理/課金通貨管理/スタミナ管理 といった 様々な小さなサービスを用意し、それらの中からゲー ムに必要なものを組み合わせてゲームを制作する
- 8. なぜ GS2 を作ろうと思ったか • 任天堂プラットフォームのゲーム開発者はサーバ の開発/運用業務を一切気にすることなく様々な ネットワーク対応ゲームを開発出来ていた • スマートデバイスでは Apple や Google のような プラットフォーマーはそこまで面倒を見てくれて いない • スマートデバイス用ゲームで使える汎用ゲーム サーバに需要があることは確実であり、現存する プレイヤーは存在しない
- 9. GS2 はゲームサーバ界の Unity に
- 10. Startup Architecture of the year 2018 Finalist . ) 1 ) 1 ) • s . ) 1 ) 1 ) ma i ) B3 2 a B 2 a iO se v 2 a ir G B3 e c a ir S m B e I ( a I 2 Ga s Entry Category: / NG P K K S 3 3 3 B / S B P / T HQOT
- 11. サーバーレス / = = PI
- 12. Serverless PaaS は黎明期 Gartner Identifies Three Megatrends That Will Drive Digital Business Into the Next Decade http://www.gartner.com/newsroom/id/3784363
- 13. 原則 n マイクロサービス指向 • 小規模で自律的なシステム • 1つの目的にフィットしている ü マイクロサービス：ビジネスの境界＝サービスの境界 ü サーバーレスで実行する各ランタイムはサービスの境界よりずっと細かい n リアクティブなアーキテクチャ • リクエストルーティング機能／状態管理／永続ストレージを コードから「分離」することで、メンテナンスしやすい最小限に維持し、生産 性を向上する n 認証・認可にもとづくリソースアクセス • ドメインの違うサービス間のリソースへのアクセスを適切な範囲に限定する n DRY • 競争力を得られない汎用機能をアウトソースする
- 14. われわれの戦いの歴史 Less Ops, More Code ちょっと振り返って みて良いですか？
- 15. PaaSの普及 2008〜 • インフラを隠蔽したソフトウェア実行基盤 →インフラや実行環境のメンテに費やす作業が減る • 12-Factor App/PaaSを活かすアプリのつくりかた • すべてがPaaSになったか • レガシーシステムの移植性 • パッケージングやポータビリティの再現性の低さ
- 16. コンテナ技術の一般化 2013(Docker)〜 • アプリごとの環境分離 • 複雑なインフラの依存性からの脱却 • すべてがコンテナ＋スケジューラーになるか • クラウドやオンプレミスのサーバーへのデプロイか の手間 • イメージのビルドプロセス • スケーラビリティの管理
- 17. FaaS 2014〜 • FaaS：コードを用意して渡すだけで実行できるソ フトウェア実行基盤 • 超並列的：キャパシティプランニング不要 • サーバーのプロビジョニング / ソフトウェアのインス トール不要 • コンテナのビルド / デプロイ 不要 • サーバーレスアーキテクチャ • 「サーバーに直接アクセスしなくても仕事ができる」 新しいソフトウェアアーキテクチャ
- 19. 理想の Less Ops, More Code. サーバーレス コンテナ オンプレミス +H/W Less Ops な調達モデル KubernetesもVM もない世界!
- 20. 検証「VMレスでゆとりな実行基盤」 • Google • Serverless containers • AWS • Lambda Custom Runtime • Lambda Layers：共有ライブラリ • IBM • Cloud Functions (Dockerコンテナ)
- 21. 溶け合うコンテナとサーバーレス • 何が問題か • セキュリティ(アイソレーション) • 実行環境を集約する際に、Docker Engineなどを使って Linux Kernelにアクセスする？ →コンテナはサンドボックスではないので、ゲストカー ネルを十分に隔離していない →脆弱性で一点突破 • 解決方法 • 安全な実行環境 • Kata Containers / gVisor / Firecracker
- 22. // . - - - - /
- 23. Firecracker • tl;dr;サーバレス・コンピューティングのため の安全で高速なmicroVM • 目的 • セキュアなアイソレーション • 高速起動 • 小さいメモリフットプリントによる集約率(スケー ル)の向上 • 類似プロジェクト • Kata Containers • gVisor
- 24. -/ . . . .
- 25. Firecracker • セキュアなアイソレーション • ネットワークデバイス、ブロックI / Oデバイス、プログラマブルインターバルタイマー、 KVMクロック、シリアルコンソール、および部分キーボードのみカプセル化してゲスト OSにデバイスアクセスを提供することでマルチテナントをセキュアに実現 • リソースのレートリミット、帯域制御 • crosvmというChrome OSのVMM(Virtual Machine Monitor)をベースに開発 • 高速起動 • 125msec ※gVisorは150msecほど • 小さいメモリフットプリント • 5MiB未満(現状3MiB台) ※gVisorは15MBほど • 動作環境 • ホストのハイパーバイザー(KVM)上のユーザー空間で動作するゲストカーネル、アプリ ケーション=ゲストOS(ALinux)に限定されたデバイスモデルを提供する • クライアントからはREST APIを介してアクセスする • Rust製：バッファオーバーフローへの耐性など • LambdaやFargateで実戦投入済み
- 26. • 安全にゲストカーネルより上を隔離できるよう になり→集約率が向上→1プロセスへのリソー スの割当が拡張可能→リソース(メモリ、タイ ムアウト)理由でコンテナ使う理由なくなる • リソース上限拡張 • メモリ： 1.5GB→3.0GB • タイムアウト： 60秒→5分→15分
- 29. 短い時間で 価値の高いもの / 素早く / たくさん デリバリー /フィードバック / 改善
- 31. AWS (2013-) サーバー台数（EC2+RDS） EC2 133(通常) ∼220(ピーク)台 RDS 22セット EC2 t1.micro 5台 RDS Small 1セット 2013 2018 ほぼ手間 なし とはいえ 無駄だらけ
- 33. チーム開発って難しいですか？ • アーキテクトと実装の分割さえできればむしろ 工程や品質管理しやすい 中山桂一さん@キャラウェブ WebもアプリもサーバーサイドはREST API化 してますが「Swagger定義」と「DynamoDB のテーブル定義」さえちゃんとできていれ ば、外部ベンダに関数ごとに制作お願いでき るんで管理しやすいですよ （明日の開発カンファレンス より） 現場的コンウェイの法則 (マイクロサービスの実践)
- 35. cydas (新サービス) のアーキテクチャ 2 N NL 2 2 GraphQL (AppSync) に移行中 C G CA D IEB D I
- 37. 組織への技術定着のためのポイント • すすめかた • できるだけサーバーレスで始める • ノックアウトな要件もFunctionalなSaaSによって 補完できるかもしれない • 意地でもサーバーレスで進める • それでもダメなら他の方法で • 組織の成熟度へのケア • 壁打ちできる人がいると想定より圧倒的に早く慣れ る(慣れないと探索的になりがち
- 41. 運用上の制約 • フルマネージドサービスを乗りこなす力 • パフォーマンスには従来以上に気を遣う必要が • レイテンシとの戦い
- 46. Startup Architecture of the year 2018 Finalist . ) 1 ) 1 ) • s . ) 1 ) 1 ) ma i ) B3 2 a B 2 a iO se v 2 a ir G B3 e c a ir S m B e I ( a I 2 Ga s Entry Category: / NG P K K S 3 3 3 B / S B P / T HQOT
- 47. OS以下の情報にアクセスできない
- 49. モニタリング層 Serverless Application Lens Amazon CloudWatch AWS X-Ray ※非同期処理はトレースされない
- 54. サービス監視
- 55. コンポーネント監視 キャパシティ管理または上限緩和の必要な項目 ・Lambda の同時実行数 ・API Gateway への Request/sec ・DynamoDB のキャパシティ使用率 障害発生時に障害点を特定するための項目 ・API Gateway の応答時間 ・Lambda の応答時間 ・DynamoDB の応答時間
- 56. GS2 ではどうしているか？
- 57. モニタリング
- 58. 異常を検出するには
- 59. 異常を検出するには
- 60. 異常を検出するには
- 61. 異常を調査するには
- 62. 想定外の例外が検出！！！
- 63. 想定外の例外が検出！！！
- 64. 想定外の例外が検出！！！
- 65. 想定外の例外が検出！！！
- 66. 想定外の例外が検出！！！
- 67. 想定外の例外が検出！！！
- 68. 想定外の例外が検出！！！
- 69. 想定外の例外が検出！！！
- 70. 想定外の例外が検出！！！
- 71. 想定外の例外が検出！！！
- 72. 想定外の例外が検出！！！
- 73. 想定外の例外が検出！！！
- 75. We are Hiring!!! ▼職種 ・プロダクトマネージャー ・UI/UXデザイナー ・フロントエンドエンジニア ・サーバーサイドエンジニア ・スクラムマスター ・プロダクティビティエンジニア ・セールスエンジニア ▼勤務地 沖縄 / 東京 / 大阪 (2019/1-) お近くのサイダスメンバーまで！