~クラウドサービスの先駆者AWSのベストプラクティス学習Vol.2~を開催しましたこんにちは。開発本部エンジニアの有働です。WorkShop(通称「水尾塾」)の第二回目の模様についてご紹介します。今回は、前回の続きとして「クラウドサービスの先駆者AWSのベストプラクティス学習Vol.2」というタイトルを冠した勉強会を行いました。場所は、新設されたAWS目黒オフィスの一室をお借りしました。AWS」について教えて頂きました。盛りだくさんで教えて頂いたので、書ききれる範囲で簡単にご紹介します。DevOpsとは?所謂、DevOpsの定義(開発チーム-Developmentと運用チーム-Operationsがお互いに協調し合って...)の話よりも、DevOpsを採用する利点に重きを置いた話をして頂きました。Startupの実践としてのDevOps)。DevOpsを実践することで「コーディング~ビルド~デプロイ~プロダクト」をWeeksオーダーからHoursオーダーにするレベルの高速化を実現します。DevOpsの効果として、ある企業では年間300を超えるアプリがリリースされたそうです。このあたりの話は個人的に興味のある分野なので、もっと詳しく知りたい方や語りたい方はお話ししに来てください。Amazonでは何をしたのかAmazonでは昔(2001年頃)、各サービスが密に結合したモノリシックなアーキテクチャとなっていたそうです。それをマイクロサービス化し、DevOpsをどのように成功させているかについて話をして頂きました。Amazonで実践されたDevOpsを成功させるためにしたことについてかいつまんで紹介します。定義や設定をコードとして扱う(極端な話、設計書はいらない)個人的には上の3つが特に重要だと感じていて、下の2つは各チームの自由の中で効率化を実践すれば勝手にできていくものだと思います。AWSDevOpsを実践する際に便利なAWSのサービスについていくつか教えて頂きました。リリースまでの全てのフェーズにAWSのサービスが存在し、各フェーズを高速化(自動化)します。ここではAWSの各サービスの詳細について言及することはしませんが、有用なサービスを列挙しますので興味のある方はググってみてください。引き続き小林様に、データレイクについて教えて頂きました。うちの「蓄積」に当たります。ビッグデータの取組みに関する課題である「ストレージコストの増加」、「セキュリティの懸念」、「データ探索の負荷」を解決するために必要です。データレイクを有効に使用するために、データレイクを「ゴミ溜め」にせず使える状態にすること(ガバナンス)、データレイクから情報を漏洩させないことを実現するアーキテクチャが必要となります。出典:https://www.slideshare.net/AmazonWebServicesJapan/20180424-aws-black-belt-online-seminar-awsデータレイクを構成するAWSのサービスデータレイクを中心として、ビッグデータ領域のAWSサービスについて紹介して頂きました。その中から小林さんが推していたサービスについて簡単に紹介します。Amazonでは多数のチームが多数のデータテーブルを参照するニーズがあり、面倒なプロセスを簡素化するためにデータレイクを実現し、様々なデータをセルフサービスで利用できるようにしたそうです。S3データレイク基盤の中心であり、ビッグデータを安全に格納するサービスです。データレイク基盤に求められる要件の多く(大容量、低コスト、セキュア、高速)をカバーしています。Glueデータレイク基盤へのETL処理を行い、連携したデータをカタログ化するサービスです。ETL処理のためのコードの生成、変更等が行えるため、データを統制をとって探索/再利用しやすい状態にできます。Athenaデータレイク(S3)に直接アクセスし、SQLによって検索分析実行できるサービスです。サーバーレスでインフラ管理の必要がなく、マネジメントコンソールから簡単にアクセスできます(利用開始から数分でクエリ実行可能)。個人的には手軽さが売りだと認識しています。出典:https://www.slideshare.net/AmazonWebServicesJapan/20180424-aws-black-belt-online-seminar-awsグループワーク今回は、チームごとに前回決めたテーマを元にしてどんなモノを作るかを具体的に決め、AWSのどのサービスをどのように使うかといったレベルまで落とし込みました。各チームで決めた内容を最後に発表し、AWSの方にアドバイスを貰う形式で進みました。欲しいデータが増えても新規APIを作成しなくてすむようにしたい。現状、欲しいデータが増えるたびに新規APIを作成している。実現すること数多あるAPIの中から簡単なAPIをAppSyncから使用できるようにする。将来的には、すべてのAPI呼出しをAppSync経由にしたい。弥生のお客様にプロアクティブにサービス提供したい。ユーザーの行動履歴を分析してアクションを起こすための基盤を作る。実現することログイン履歴を分析し、分析結果に応じてメールを送信する。職場環境の快適を作りたい・知りたい・維持したい。実現することユーザーからの要望をAlexaが受け付け、空調の温度を調整するユーザーからの要望を蓄積する蓄積された要望を素にユーザー要望を先回りして叶えるばらグループ目的PCを起動しなくても出勤の打刻をしたい。実現することタブレット等のカメラに顔を写すことで打刻をする。備考まずは最低限の機能のモノを作り、その後改善していく。顔の様子から元気がなければ上司にメールする機能など、発展させていく。勤怠連絡を楽にしたい。コールセンターをイマドキにしたい。Connectを用いて構築する。わしっぱなグループ目的コールセンターの業務を効率化したい。実現することかかってきた電話の音声ファイルを使って、障害などをリアルタイムに検知する仕組みをつくる。蓄積された音声データを分析して、よくある質問などにフィードバックする仕組みをつくる。今回イメージ化した内容を各グループでさらに具体化し、アーキテクチャレビューを実施予定です。実施した内容は本ブログで公開します。~クラウドサービスの先駆者AWSのベストプラクテ...こんにちは。de:code2018に参加しました!テスト自動化チームの相澤です。前回の記事でT.Aさんが紹...2017-06-16息を吐くようにシンプルにMackerelを導入してみたはじめまして。アーカイブはてなブログをはじめよう!yayoiTechさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。