Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to 実務で活かせる AWSアーキテクチャ設計 〜AWS re:Invent 2016アップデート最新版〜
Similar to 実務で活かせる AWSアーキテクチャ設計 〜AWS re:Invent 2016アップデート最新版〜 (20)
More from 真吾 吉田
More from 真吾 吉田 (20)
Recently uploaded
Recently uploaded (9)
実務で活かせる AWSアーキテクチャ設計 〜AWS re:Invent 2016アップデート最新版〜
- 1. 2016.12.20 株式会社セクションナイン 吉田真吾 実務で活かせる AWSアーキテクチャ設計 〜AWS re:Invent 2016アップデート最新版〜
- 2. 吉田真吾 n バックグラウンド 証券システム基盤開発 p 基盤開発、Oracleチューニングなど エバンジェリスト p 講演年間113回(2013年実績) p AWS設計・構築・移行(2014-2015) n 現在のしごと (株) セクションナイン 代表取締役社長 p AWSコンサルティング〜実装まで (株) Cloud Payment p 技術顧問 n 実績等 p AWSウルトラクイズ 初代チャンピオン (2012年) p AWS Samurai 2014 p AWSエキスパート養成読本 執筆 p AWS認定全資格(5種類) p Oracle Database 11g認定 (OCP, Performance Tuning)
- 3. 実績 • ブレインラボ様 • Oracleデータベースチューニング • 彦根建築設計事務所様 • ワークスタイル改革（情報システム全面刷新） • 業務コンサルティング会社様：複数PJ • PoC、デモシステム構築 • データ分析基盤構築 • DevOps定着化・CI/CDパイプライン構築 • SaaSify支援 • 大手インターネット事業会社様：複数PJ • ITSMS・運用改善支援 • インフラ設計・構築 • トラブルシューティング • Cloud Payment：開発チーム内製化、クラウド移行支援など
- 4. Mobingi クラウドアプリケーションライフサイクルマネジメント http://thebridge.jp/2015/11/mobingi-fundraises-from-500-startups
- 10. AWS re:Invent 2016 • 2016/12/5(月)-9(金)：5日間 • 参加者 32000人 • 開催5回目 • 500以上のブレイクアウト セッション • 29の新発表 • Martin Garrix @ re:Play (No.1 DJ @TOP 100 DJs 2016) https://aws.amazon.com/jp/about-aws/events/reinvent2016-1129/
- 12. AWS売上高 $0 $5,000 $10,000 2013 2014 2015 2016 百万 (x100万) 予測 サービス数 l 2006 : 4 l 2007 : 5 l 2008 : 6 l 2009 : 11 l 2010 : 13 l 2011 : 20 l 2012 : 27 l 2013 : 35 l 2014 : 46 l 2015 : 61 l 2016：91“Products”@aws.amazon.com+SimpleDB+Mechanical Turk APNプレミアコンサルティングパートナー 2013 17 2014 22 2015 28 2016 46 AWS Shield Amazon Athena AWS Glue AWS Batch AWS Step Functions Amazon Lex Amazon Polly Amazon Rekognition Amazon Lightsail AWS CodeBuild New Services & Enhancement 2017 55 AWS X-Ray AWS Snowmobile Amazon Pinpoint Amazon EC2 F1: FPGA Elastic GPU C5/R4/I3 T2: xlarge/2xlarge Systems Manager Lambda C# Lambda@Edge AWS Greengrass AWS Snowball Edge VMware on AWS Cloud AWS Personal Health Dashboard AWS OpsWorks for Chef Automate
- 13. AWS’s Innovation at Scale Tuesday Night Live with James Hamilton https://www.youtube.com/watch?v=AyOAjFNPAbA
- 14. https://www.youtube.com/watch?v=AyOAjFNPAbA 10年前のAmazonのサーバー規模を毎日追加 • 2015年AWSは ”2005年のAmazon （年商85億ドル）で 必要だったサーバー 規模” を毎日追加 • FORTUNE500社の サーバー規模の合計 分と同等 • Amazon Prime Day を ターゲットに調達
- 17. https://www.youtube.com/watch?v=AyOAjFNPAbA リージョンやAZの構成 • 世界に14リージョンあり • 最低2AZ以上 • 新規は3AZ以上 • 多いところは5AZ • リージョンとインターネット間の トランジットセンターは2箇所で冗長化 • AZ内やAZ同士をつなぐメトロの光ケーブル • 126の独自経路 • 242,472本の束
- 24. ITサービスマネジメントとは • 顧客のニーズに合致した適切なITサービスを提 供するマネジメント活動全般 • ITサービスマネジメントの各種規格は、組織が サービスマネジメントシステムを計画、確立、 導入、運用、監視、レビュー、維持するための サービス提供者に対する要求事項を規定した規 格 • 必要な能力はITスキル標準(ITSS)や情報システ ムユーザースキル標準(UISS)にて明確化・体系 化されている
- 25. ITサービスマネジメントの規格 • ITIL (ITインフラストラクチャライブラリ) • 要求プロセス＆ベストプラクティス集 • 現在 ITIL V3 • BS 15000 • 英国規格 • ISO/IEC 20000 • ISO規格 • ISO/IEC 20000-1:2011, ISO/IEC 20000-2:2011 • JIS Q 20000 • JIS規格 • JIS Q 20000-1:2012, JIS Q 20000-2:2012 • ITSMS適合性評価制度
- 26. JIS Q 20000:2012 • 規格 • JIS Q 20000-1 • 情報技術 ― サービスマネジメント ― 第1部：仕様 • ITサービスマネジメントの実施基準 • JIS Q 20000-2 • 情報技術 ― サービスマネジメント ― 第2部：実践のため の規範要求プロセス群 • ITサービスマネジメントの認証基準
- 28. ITSMSの運用プロセス n設計及び移行 • 新規サービス又はサービス 変更の設計及び移行 nサービス提供プロセス • サービスレベル管理 • サービスの報告 • サービス継続及び可用性管 理 • サービスの予算業務及び会 計業務 • 容量・能力管理 • 情報セキュリティ管理 n関係プロセス • 事業関係管理 • 供給者管理 n解決プロセス • インシデント及びサービス 要求管理 • 問題管理 n統合的制御プロセス • 構成管理 • 変更管理 • リリース及び展開管理
- 31. 設計 • Well-Architected Framework • 基本の設計原則 • 五本柱 1. セキュリティ 2. 信頼性 3. パフォーマンス効率 4. コスト最適化 5. オペレーションの改善 https://aws.amazon.com/jp/whitepapers/ → AWS Well-Architected Framework
- 32. 一般的な設計原則 • キャパシティの需要予測をやめよう • 本番環境同等の環境でテストしよう • アーキテクチャ検証を簡単に行うために自動化 しよう • 漸進的にアーキテクチャを変更していこう • データドリブンアーキテクチャ • ゲームデイ（リハ）を通じて改善しよう https://aws.amazon.com/jp/whitepapers/ → AWS Well-Architected Framework
- 33. 1. セキュリティ • すべてのレイヤーでセキュリティを作り込もう • トレーサビリティを確保しよう • 最小権限の原則を実践しよう • 自分の担当範囲のセキュリティにフォーカスし よう（インフラはAWSにまかせる） • セキュリティを自動化しよう https://aws.amazon.com/jp/whitepapers/ → AWS Well-Architected Framework
- 35. https://aws.amazon.com/jp/organizations/ AWS Organizations • アカウントをグループ 化し、セキュリティや 自動化設定を一元管理 できる • AWSアカウントの作成 を自動化できる • 一括請求の設定が簡単 にできる
- 36. 2. 信頼性 • リカバリー試験を行おう • エラー発生時には自動リカバリさせよう • 水平スケールさせることでシステムの可用性を 向上しよう • キャパシティを気にすることをやめよう • 変更管理を自動化しよう https://aws.amazon.com/jp/whitepapers/ → AWS Well-Architected Framework
- 37. 3. パフォーマンス効率 • 高度な技術を逐次採用するようにしよう • 一瞬でグローバル化できるようにしよう • サーバーレスアーキテクチャを採用しよう • たくさん検証しよう • 機械的な相性を考慮しよう https://aws.amazon.com/jp/whitepapers/ → AWS Well-Architected Framework
- 38. 4. コスト最適化 • 使った分だけ払うモデルに対応しよう • 規模のスケールの恩恵を受けよう • AWSはグロースに合わせて値段が安くなっていき ます • データセンターの運用にお金を使うのをやめよ う • システムごとのROIを可視化して分析しよう • マネージド・サービスを利用することで所有コ ストを減らそう https://aws.amazon.com/jp/whitepapers/ → AWS Well-Architected Framework
- 39. Amazon ECS AWS Elastic Beanstalk AWS Lambda Elastic Load Balancing Amazon CloudFront Amazon EFS Amazon Glacier Amazon S3 AWS Import/ Export Snowball AWS Storage Gateway Amazon Redshift Amazon DynamoDB Amazon ElastiCache Amazon RDS AWS Database Migration Service Amazon Route 53 AWS CodeCommit AWS CodeDeploy AWS CodePipeline Amazon CloudWatch AWS CloudFormation AWS CloudTrail AWS Config AWS OpsWorks AWS Service Catalog Amazon Inspector AWS CloudHSM AWS Directory Service ACM AWS IAM AWS KMS AWS WAF Amazon Elasticsearch Service Amazon EMR Amazon Kinesis Amazon Machine Learning Amazon QuickSight AWS Data Pipeline AWS IoT Amazon GameLift Amazon Cognito Amazon Mobile Analytics Amazon SNS AWS Device Farm AWS Mobile Hub Amazon API Gateway Amazon AppStream Amazon CloudSearch Amazon Elastic Transcoder Amazon SES Amazon SQS Amazon SWF Amazon WorkDocs Amazon WorkMail Amazon WorkSpaces
- 40. 5. 運用の卓越さ • コードで運用しよう • 運用プロセスをビジネス目標に合わせよう • 定期的／小規模／断続的に変更を加えよう • 予期しないイベントへの対応の試験をしよう • オペレーションイベントやエラーから学ぼう • オペレーション手順をつねに最新化しよう https://aws.amazon.com/jp/whitepapers/ → AWS Well-Architected Framework
- 43. ITスキル標準(V3)におけるITサービスマネジメント 共通スキル • 関連知識 • 顧客対応 • 要員管理 • 情報資産管理 • テクノロジ • ビジネスマネジメント • プロジェクトマネジメント • リーダーシップ • コミュニケーション • ネゴシエーション 専門分野固有スキル(運用管理) • ITサービス管理 • ITサービスマネジメント導入計画 立案、セキュリティ管理 • サービスデリバリ • サービスレベル管理、可用性管理、 キャパシティ管理、ITサービス財 務管理、ITサービス継続性管理 • サービスサポート • インシデント管理、問題管理、変 更管理、リリース管理、構成管理 • ファシリティマネジメント • データセンタ施設の防犯と防災等 の安全管理関連知識、ファシリ ティマネジメント関連法規と基準 の基礎知識、設備管理 http://www.ipa.go.jp/jinzai/itss/release20120326.html
- 44. ITスキル標準(V3)におけるITサービスマネジメント 専門分野固有スキル(システム管理) • ITサービスマネジメント業務管理 • ITサービスマネジメントの業務フ ロー分析、運用業務管理システムの 導入・設定、運用業務管理システム の運用管理 • アプリケーション管理 • 運行管理、障害時運用方式、性能管 理、構成管理、アプリケーションシ ステムの受け入れ • システムプラットフォーム管理 • 共通基盤としてのプラットフォーム 設計構築、プラットフォームシステ ム管理、システムプラットフォーム の受け入れ • データベース管理 • 共通基盤としてのデータベー ス設計構築、データベースシ ステム管理、データベースシ ステムの受け入れ • ネットワーク管理 • 共通基盤としてのネットワー ク設計構築、ネットワークシ ステム管理、ネットワークシ ステムの受け入れ • セキュリティ管理 • セキュリティ技術、最新セ キュリティ情報の収集 http://www.ipa.go.jp/jinzai/itss/release20120326.html
- 45. ITスキル標準(V3)におけるITサービスマネジメント 専門分野固有スキル(オペレーション) • プラットフォームオペレーション • プラットフォーム技術（ハードウェア）、 プラットフォーム技術（ソフトウェア）、 プラットフォーム製品知識 • ネットワークオペレーション • ネットワーク技術、ネットワーク製品知 識 • ITサービスオペレーション • 業務知識、業務システムオペレーション、 ジョブスケジュール、システムの監視、 稼働状況管理、障害管理、帳票デリバリ、 媒体管理 • スタッフィング • 品質・スキルの維持、勤務スケジュール 管理 専門分野固有スキル(サービスデスク) • 顧客サポートスキル • 対人スキル、聞くスキル、会話するスキル、書くスキル • ナレッジマネジメント • ナレッジマネジメントの意義、ナレッジベース、ＦＡＱ • サポートセンタのインフラに関する知識 • コンピュータテレフォニー、コールトラッキングシステム、イ ンシデント管理システム、ナレッジマネジメントシステム • 個別業務 • 業務知識 • スタッフィング • 要員の品質・スキルの維持、勤務スケジュール管理 • サービスデスクの管理指標 • 測定指標、モニタリング手法 • サービスサポート • インシデント管理プロセス http://www.ipa.go.jp/jinzai/itss/release20120326.html
- 46. Serverless 化する世界
- 49. パラダイムシフト • Why The Future Of Software And Apps Is Serverless by Ken Fromm, VP of Business Development at Iron.io • コンピューティングリソースの調達リードタイムの短縮 • スタンダローンアプリからの変化（現在のMicroservices） • クラウドで柔軟にコンピューティングリソースをサービスとして 利用することができる • サーバーが要らないということではなく、開発者はサーバーにつ いて「考えなくてもよくなる」 http://readwrite.com/2012/10/15/why-the-future-of-software-and-apps-is-serverless/
- 50. Functions as a Service の台頭 • 特徴 • 実行環境は隠蔽＆プラットフォーム 管理で、必要なのはコードのみ • コンテナベースで調達リードタイム を短縮 • 分散実行環境による可用性の確保 • 実行時間のみ課金によるコスト低減 • アーキテクチャにおける責務 • Stateful >> Statelessへ • 永続データ >> 揮発性 • モノリシック >> Microservices • バッチ処理 >> イベントドリブン https://aws.amazon.com/jp/about-aws/events/reinvent-report-2014-pt2/
- 51. FaaS の主要な特徴 • スケーラビリティ • ユーザーはスケールを気にしなくてもコードの実行に必要なリ ソースが適宜適量割当てられる • 可用性 • コンテナベースであるためポータブルで瞬時に動的に実行環境の 割当てが行われる→実行時に健全なリソースが使えるという意味 で可用性が高い（プラットフォーム次第） • 使った分だけ課金 • 実行したリソース分だけ課金。永続的にプロビジョンするリソー スはないので合理的。 • 制約 • データの永続化は外部の仕組みが必要（ステートレス） • 実行環境の言語やバージョンにより利用可能なライブラリに制約 があったりする
- 52. Functions as a Service
- 53. AWS Lambda • 2014年末 re:Invent にて発表 • サポート言語 2016.12.11現在 • Node.js – v0.10.36, v4.3.2 • Java – Java 8 • Python – Python 2.7 • C# - .NET Core 1.0.1 • ホスト • Amazon Linux (時々バージョンアップ) • 実行環境は再利用される • 初回起動が遅いが再利用時は高速 • 一時ストレージとして /tmp 利用可能（スケールしたり破棄されたりするので 頼らないこと） • 課金は使った分だけ • 確保(指定)したメモリ(128MB〜1.5GB) x 実行時間(100ms単位) x 実行回数 • メモリに比例してCPUの割当ても多くなる http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html
- 56. Visual Studio + Lambda C# でローカルデバッグ • ローカルの.NET Core上で実行ができる • クラウド上のリモートデバッグには対応していない • ユーザー側のFunction上の変数の値は見えるが、 Lambdaのコア側の変数は見えない • シームレスにクラウド上にデプロイしてIDEか ら直接ソースの修正できる • 俺Macだから… • BootCampがあるで • Visual Studio for Mac は Xamarin やで
- 58. サーバーレスアーキテクチャ フルマネージドなアプリケー ション実行環境 • Functional SaaS/mBaaS/PaaSなど で実現するサーバーレ ス環境を指すことが多 い • FaaSよりFunctional SaaS使うほう が効果的 コンポーネント同士をつなぐ アーキテクチャ • コンポーネントとして、 あるいはコンポーネン ト自体として中央集権 的なサーバーを廃して • 例）一部のマイクロ サービスにFaaSを使う。 マイクロサービス間の イベントハンドリング にFaaSを使う
- 59. UIドリブンアプリケーション • Backend For Frontendでサーバー レス活用 1. 認証ロジックをBaaSで置換え 2. DynamoDBにクライアントから直 接アクセスするように 3. 大半のロジックをクライアントの シングルページアプリケーション に(UXに気をつける)してサーバー 側はAPI Gatewayで束ねる 4. 検索機能をFaaS上に 5. セキュリティの考慮で課金は別DB に別FaaSでアクセスするように http://martinfowler.com/articles/serverless.html
- 60. メッセージドリブンアプリケーション • オンライン広告システム • 素早い配信(と同時に) アクティビティ記録 • 非同期にサーバーに送信してい た部分をスケーラビリティを気 にしなくていいFaaSに送信 • その他、アップロードコンテン ツのサムネイル作成など http://martinfowler.com/articles/serverless.html
- 61. プラットフォーム事業者 フレームワークやツール アプリケーション開発者 サーバーレスエコシステム • サーバー構築不要 • スケーラブル • 従量課金 etc… • API定義と関数コード の一体管理 • チーム開発（テスト、 デプロイ） etc… • 企画→開発→デリバリーに 集中 • サービスマネジメント • etc…
- 62. 10X Product Development • 製品がマーケットにフィットす るかどうかが最も重要である • ビジネスに関連するコードの開 発時間に極力時間を使うべきで ある • 顧客とまわすイテレーションを 最大化すべきである • 依存性を最小化すべきである： 仕様確定待ちで開発者を待たせ たり、運用やDBAやその他の開 発者の影響で待たせることを極 力避けるべきである http://www.slideshare.net/ServerlessConf/joe-emison-10x-product-development
- 63. 10X Product Development • Commercial Search • 2人の開発者で4ヶ月で作った • 13,307行のTypeScript • 開発者の稼働は95%以上だった(なにかに依存した待 ち時間はほとんどなかった) • コンセプトはMicroservicesだが、自分たちはコアし か書いていない • 構成 • Auth: Firebase • Static Site Hosting: Netlify • 画像管理: Cloudinary • 検索: Algolia • ペインポイント • Firebaseのダッシュボードでは大きなデータセット が扱えない（APIであればOK） • RDBMSからFirebaseに移行する開発者のラーニング カーブは人それぞれ、非常識ってほどではないけど http://www.slideshare.net/ServerlessConf/joe-emison-10x-product-development
- 64. From serverless to Service Full • サーバーレスな構成のために積極的に SaaSを使うことが増えた • ITサポートサービス：DataDog, GitHub, CircleCIなど • オフィスサービス：Gppgle Apps, Slack, Dropbox, Google Calendar, Skype, Trello, Google Hangoutなど • コミュニティサービス：npm, ubuntu, coreos, NTP, Docker Registryなど • フロントエンドサービス：jQuery, Google font api, AngularJS, Google Analytics • モバイルサービス：AWS Device Farm, Amazon Mobile Analytics, SNS, Cognito, App Annie, AppStore, Google Play Store, fabric, New Relic, ComScore https://www.slideshare.net/jedi4ever/from-serverless-to-service-full-how-the-role-of-devops-is-evolving
- 65. From serverless to Service Full • サービスの可用性に依存しているので、GitHubが落 ちたらシゴトができない、みたいなことがよく起きる • 文書化されてない変更が入ったりする（CircleCIの 例） • ELBは事前暖機が必要で、忘れて急にトラフィック受 けると何もできずにエラーが大量に返ってしまう • サーバーレス、というかサービスフルな状態で 【SaaSがダウンしてサービスが継続できないリスク が上昇している】
- 66. From serverless to Service Full • Lambdaのサービスの内部仕様 • Lambdaのコンテナの再利用ルールは非決定 • スケールは常に無限というわけではない • DevOpsを採用して、リモートAPIを駆使する • RSSでAWSの障害を監視 • Google Scanningを用いたGoogle Appsのデータのバックアップ • Slackを用いてステータス変更を素早くフィードバックできるようにする • (ポストモーテムなどを読んで)何に依存しているか明らかにする • カンファレンスでサービスへの希望を共有する • 他の人に経験をフィードバックする • 自分を頼りにしてくれる人たちにも知ったことを教えてあげる • 同僚のエンジニアたちにおそれずに情報交換すべきであるということを示す • 要望されていることに対する責任を持つ • DevとOpsのコラボレーションはいまや外部のサードパーティベンダーにまで広がって いることを認識する
- 67. Serverlessness, NoOps and the Tooth Fairy • 来たるサーバーレスな未来では、アプリ ケーション開発者がもっと運用品質に対 する責任を担うことになる • インフラは外部にホストしてるから運用の ことは考えたくないと言っても、アプリが 落ちているかもしれない状況においてはど んな変更があったか、サービス側の問題か、 切り分ける必要性がある • 運用とはなにか？ • 運用は自分の組織の技術スキルや練習、デ ザイン周りの文化づくり、システムの構築 やメンテナンス、ソフトウェアのデリバ リー、技術的な問題の解決 "In the glorious Future, we will be Serverless, and there will be NoOps. - thought leaders" http://www.slideshare.net/ServerlessConf/charity-hound-serverless-noops-the-tooth-fairy
- 68. Serverlessness, NoOps and the Tooth Fairy • 運用とはなにか？ • 運用は自分の組織の技術スキルや練習、デ ザイン周りの文化づくり、システムの構築 やメンテナンス、ソフトウェアのデリバ リー、技術的な問題の解決 • 運用エンジニアのコアコンピテンシー • スケーラビリティ • レジリエンシー • 可用性 • メンテナンス性 • 複雑なシステムを簡素化するモニタリング の実装と可視性 • グレイスフル デグラデーション：ソフト ウェアのアップグレードなど http://www.slideshare.net/ServerlessConf/charity-hound-serverless-noops-the-tooth-fairy
- 69. Serverlessness, NoOps and the Tooth Fairy • サーバーレス運用工学のベス トプラクティス • あなたのプロダクトの問題はあ なた以上にちゃんと直せる人は いない • クリティカルパスを理解する • できるかぎり小さく維持する • SaaSプロバイダの技術情報と、 何にどう依存しているか理解す る • アウトソース先に問題が起きても、 自身のサービスにおけるそれによ る結果については依然としてあな たが責任を持たなければいけない http://www.slideshare.net/ServerlessConf/charity-hound-serverless-noops-the-tooth-fairy
- 70. Serverlessness, NoOps and the Tooth Fairy • トレードオフ • 可視性が下がる • 自分自身で問題をfixできない し、新機能を実装することも できない • サービスはあなたの支払うお 金で維持されている • 制限や制約は公開されること もあるし、公開されないこと もある http://www.slideshare.net/ServerlessConf/charity-hound-serverless-noops-the-tooth-fairy
- 71. リクルートジョブズ • タウンワークにおけるサー バーレスアーキテクチャデ ザイン • CTL(データサイエンティス ト集団)が機械学習ロジッ クに集中できる環境 • ログ基盤を整備し、カスタ マーの回遊や検索における リアルタイムな特徴量の更 新や、バッチ処理による予 測モデルの作成に利用 https://techblog.recruitjobs.net/events/aws-summit-tokyo-2016-townwork-serverless-architecture-design
- 76. サーバーレス関連アップデート • AWS Lambda が環境変数をサポート • AWS Serverless Application Model (SAM) リリース • [New] AWS Greengrass • [New] AWS Snowball Edge • [New] AWS Step Functions • [New] Lambda@Edge • Amazon Kinesis Firehose が Lambda に対応(予定) • AWS Lambda が C# をサポート • AWS Lambda Dead Letter Queue
- 77. AWS Serverless Application Model (SAM) • サーバーレスアプリケーション全体 を CloudFormation テンプレートで 管理できる • Lambda、API Gateway、 DynamoDB がサポートされている • 個人的には今後チーム開発はこれが もっともやりやすく（Serverless FrameworkやChaliceより）なるん じゃないかと想定 https://github.com/awslabs/serverless-application-model
- 78. AWS Serverless Application Model (SAM) functions app-spec (template) functions.zip Lambda bucket DynamoDB stack CloudFormation API Gateway SAM http://yoshidashingo.hatenablog.com/entry/2016/12/05/024120
- 79. Why NOT CodeBuild ?? machine: timezone: Asia/Tokyo dependencies: override: - sudo pip install awscli post: - aws configure set region $REGION test: override: - echo "Nothing to do here” deployment: production: branch: master commands: - zip app.zip index.js - aws cloudformation package --template-file app-spec.yml --output-template-file app-spec.deploy --s3-bucket $S3_BUCKET_NAME - aws cloudformation deploy --template-file app-spec.deploy --stack-name $STACK_NAME --capabilities CAPABILITY_IAM circle.yml 環境変数がないとお話にならない…
- 80. Lambda Everywhere!! Snowball Edge Greengrass AWS IoT Greengrass Core IoT SDK Gateway edge location edge location Origin Lambda@Edge Step Functions Inline processing for Kinesis Firehose
- 81. AWS Lambda Dead Letter Queues (DLQ) • 非同期でLambda Functionを呼び出す場合 のリトライはデフォルト で2回(計3回) • SQSあるいはSNSトピッ クにエラーイベントを送 信することで、メール通 知やリトライの継続など を制御できるように https://aws.amazon.com/jp/blogs/compute/robust-serverless-application-design-with-aws-lambda-dlq/
- 82. Azure Functions • 2016/3 プレビュー → 2016/11 GA • サポート言語 • C#、F#、Node.js、Python、PHP、Batch、Bash、その 他実行可能な言語(Bash叩けりゃPerlだってイケる) • リソース割当て • 動的ホスティング プラン：自動的に割当てを行い実行 • App Serviceプラン：App Serviceと統合（が詳細不明） • Visual StudioからAzure上の実行環境のメモリに アタッチしてリモートデバッグできる • HTTPトリガーなどEndpointがAll-in https://azure.microsoft.com/ja-jp/services/functions/
- 83. Apache OpenWhisk • 2016/2 IBM BlueMix 上のサービスとしてベータ提供開始 当初よりコードをOSSとして公開 →2016/11 Apache Incubator へ登録(正式採用を目指している状 態) • サポート環境 • Node.js, Swift, Python, Java, Docker(←要はなんでもOK) • 実行環境をMacのDocker環境上にセットアップできるのでローカル実行/ デバッグなども可能 • 料金 • IBM BlueMix OpenWhisk ：ベータ • オンプレにデプロイできる Serverless on Servers • その他 • IBMが啓蒙に非常に前のめり http://openwhisk.org
- 84. Google Cloud Functions • 2016/2 アルファプレビュー • サポート言語：Node.js • トリガー • HTTPトリガー • Cloud Pub/Subトリガー • GCP内の各種サービスからPub/Subトピックにイベントをエクスポートすることでトリガーすることができる • ex. Stackdriver Logging→Pub/Sub→Functions→なにか • ex. GMail Push→Pub/Sub→Functions→なにか • Cloud Storageトリガー • オブジェクトの追加（作成）、アップデート（変更）、削除 • ダイレクトトリガー • CLIから直接呼び出し • デプロイ • Cloud StorageバケットにZipアップロード(or CLI)してデプロイ • Cloud Repositoriesを使ってGitHubなどから自動(or CLI)でデプロイ • ロギング • CLI： $ gcloud alpha functions get-logs • ダッシュボード（Cloud Platform Console） • Logging API https://cloud.google.com/functions/
- 85. Auth0 Webtask • 言語サポート：Node.js • 認証サービスAuth0と連携したトークンの発行〜 Functionをコールするプロセスがシンプル • またGetting Startedの中で指定されるトークン付きの API • 認証後のJWTの内容も自分でカスタマイズできる • ソースは専用のクラウドIDE (エディタ、実行/停止、 ログ出力など)で編集 • Warm Pool で実行環境のコンテナを暖機するので Lambdaのように初回遅くないというのが売り
- 86. • Dockerベースのコア環境 • Function formatに沿えばどんな言語の実行環境も 載せられる • 2016/11 αリリース → 2017/3 のGAを目指す • Lambdaのコードと完全互換をうたっており、 Lambdaのローカル環境として期待できる(か も)
- 87. ソースコードを公開している FaaS • ソースコードの可視化 • コア／SDK／サンプル など • コントリビューターや開発者を取り込み開発を促進 • 規模の経済が働くプラットフォーム事業との切り離し • FaaSデファクトなLambdaとは違うオンプレFaaSのニーズに対応 • オンプレで使う場合リソーススケジューラは自前で実装する必要があ り課題（将来的に既存のコンテナスケジューラと統合されるといい な） MIT Apache License, Version 2.0Apache License, Version 2.0MIT
- 88. FaaSを活用するための心構え • システムをリアクティブに設計する • マイクロサービスとして、あるいはマイクロサービスごとの つなぎとして • 業務システムへの適用が難しいと言われがちだが、 そもそもFaaSのみでシステム構築するアプローチはよくない • イベントの発火やWebhookなどに対応している周辺のマネー ジド・サービスとうまくつないでいく • やっていく気持ち • 一度トライアルしておくといざ活用する際にハマりどころな どが判断しやすい • 弊社では新規事業の検討などでデモを作成することが多いた めサーバーレスでさっと構築できる環境に事前に慣れておく ことが多い
- 89. Amazon Lightsail • みんな大好きVPS • ミドルウェアセット アップ済みも選択可能 • WordPress、Nginx、 Node.jsなど https://aws.amazon.com/jp/blogs/news/amazon-lightsail-the-power-of-aws-the-simplicity-of-a-vps/ • 3クリックで起動 • ポート(Security Groups 相当)編集可能
- 90. Amazon Lightsail • 今のところUS-EASTのみ https://aws.amazon.com/jp/blogs/news/amazon-lightsail-the-power-of-aws-the-simplicity-of-a-vps/ • ブラウザで簡単にSSH (クライアントからも可) Google Cloud Shell みたいなもの
- 92. Amazon Lightsail https://aws.amazon.com/jp/blogs/news/amazon-lightsail-the-power-of-aws-the-simplicity-of-a-vps/ $ ab -c 100 -n 10000 http://54.86.210.133/ Server Software: nginx/1.10.2 Server Hostname: 54.86.210.133 Server Port: 80 Document Path: / Document Length: 3966 bytes Concurrency Level: 100 Time taken for tests: 200.566 seconds Complete requests: 10000 Failed requests: 0 Total transferred: 42520000 bytes HTML transferred: 39660000 bytes Requests per second: 49.86 [#/sec] (mean) Time per request: 2005.659 [ms] (mean) Time per request: 20.057 [ms] (mean, across all concurrent requests) Transfer rate: 207.03 [Kbytes/sec] received ： ：
- 93. Site Reliability Engineering How Google Runs Production Systems https://landing.google.com/sre/
- 94. Google以外でも現在は 広く採用されている Netflix SRE の職務定義書 • 職責 • 効果的なツールの利用やアラート、信頼性に対するリス クを識別し取り組む責任 • パフォーマンスと信頼性のチームにおいて他のチームと ともにオンコールのローテーションに参加する • 継続的な信頼性を向上させるために、プロダクトの停止 においてトリアージ作業を行い、プロダクトのエンジニ アリングチームと連携し対策を実施する責任 • 信頼性やパフォーマンスを向上させるために、クラウド 関連の最適化やベストプラクティスを定義し伝道する • 必須要件 • 高トラフィックな大規模分散システムで生じる不安定さ の根本原因を解決できる能力 • Linux/Java/Tomcatや他のミドルウェア技術における設 定や障害対応経験 • 信頼性の観点からの大規模で複雑なシステムの理解力 • pythonかperlかJVMベースの言語でのコーディング力 • 信頼性の問題を解決する情熱と今後の戦略を見極める力 Facebook, Netflix, Dropbox, etc… 日本でも • メルカリ→”インフラチーム改め Site Reliability Engineering (SRE) チームになりました” http://tech.mercari.com/entry/20 15/11/18/153421 ちょっとしたまとめ • Site Reliability Engineering(SRE) チームとは http://yoshidashingo.blogspot.jp/ 2016/03/what-is-sre.html
- 95. “ソフトウェアシステムの一生の圧倒的大部分を占め るのはそれを利用している期間であり、設計したり 構築している期間ではありません。なのになぜ従来 の多くの知識体系では、ソフトウェアエンジニアが 大規模な設計や開発に焦点を当てることばかり主張 しているのでしょうか？” “このエッセイ・記事集では、GoogleのSite Reliability Engineeringチームの主要メンバーたちが、 なぜライフサイクル全体へのコミットメントするこ とが、世界規模で展開する大規模なソフトウェアシ ステムのビルド、デプロイ、モニタリング、メンテ ナンスを可能にするかを説明しています。” Site Reliability Engineering @Back Cover https://landing.google.com/sre/book.html
- 96. Table of Content Part 1. イントロダクション 1.イントロダクション 2.SRE視点から見る Googleの本番環境 Part 2. 原則編 3.リスクを受け止める 4.サービスレベル目標 5.苦行を排除する 6.分散システムの監視 7.Googleの自動化の進化 8.リリースエンジニアリング 9.シンプルさ
- 97. Table of Content Part 3. 実践編 10.時系列データから取得する実用的なア ラート 11.オンコール生活 12.効果的なトラブルシューティング 13.緊急対応 14.インシデントの管理 15.ふりかえり(検死)文化：失敗から学ぶ 16.追跡の停止 17.信頼性のためのテスト 18.SREのソフトウェアエンジニアリング 19.フロントエンドでおこなう負荷分散 20.データセンターでおこなう負荷分散 21.過負荷のあつかいかた 22.連鎖障害への対処 23.緊急度の管理：信頼性のための分散合意 手法 24.Cronをつかった分散定期スケジューリン グ 25.データ処理パイプライン 26.データ整合性：書いたものを読む 27.大規模環境での信頼性高い起動方法
- 98. Table of Content Part 4. マネジメント編 28.SREをオンコールやその先に 29.割り込みへの対処 30.運用負荷で埋もれてしまう SREをリカバリする 31.SREにおけるコミュニケー ションとコラボレーション 32.進化するSREエンゲージメン トモデル Part 5. まとめ 33.他の業界から学ぶ教訓 34.まとめ 付録 A) 稼働率表 B) 本番サービスのためのベストプラ クティス集 C) インシデント状況報告書（例） D) 障害報告書(検死報告書)（例） E) サービス調整チェックリスト F) 本番議事録（例）
- 99. 1. イントロダクション • システム管理者のアプローチからサービスマネ ジメントへ • ソフトウェア・エンジニアリングで問題解決を行え る人間を採用しはじめた • Googleのサービスマネジメントへのアプロー チ＝Site Reliability Engineering
- 100. 5. 苦行を排除する • 苦行の定義 • 苦行＝マニュアル作業、反復作業で本番環境に縛ら れ、グロースにより直線的に増える作業 • なぜ苦行は少ないほうがよいのか • 日々の50%以上を将来の苦行を取り除く作業に充 てることでサービスをスケールアップする
- 101. 7. Googleの自動化の進化 • 自分の仕事をなくすために自動化せよ：すべて のものを自動化せよ！ • Borg(クラスタ管理システム)上にアドDBのMySQL を載せて30秒以内の自動フェイルオーバーを実現 • 信頼性は「基本機能」 • 自動制御やレジリエントな機能が信頼性を作る
- 102. 8. リリースエンジニアリング • 哲学 • セルフサービス：完全自動化 • 高速：すべてのリグレッションテストに通過したらリ リースされる • 密封されたビルドプロセス →リリース管理者ではあるがリリース作業者ではな い
- 103. 15. ふりかえり文化 • Postmotem＝検死報告書＝障害の詳細な経緯 をまとめたレポート • 項目例→付録D:障害報告書(例) • インシデント#、日付、ステータス、サマリ、顧客 影響、根本原因、発生要因、解決方法、課題作業、 教訓（うまくいったこと、失敗したこと、ラッキー だったこと）、タイムライン
- 104. 22. 連鎖障害への対処 • サーバー過負荷 • 連鎖障害をおよぼすもっとも多い原因 • 当該クラスタの切り離し • リソースの使いはたし • 原因別に対処 • サービス利用不可