ヤマムギ

growing hard days.

*

AWS Summit Tokyo 2017 聴講したセッションのメモ

      2018/01/03


2017年6月に参加しましたAWS Summitで聴講したセッションのメモを記します。

公式の資料、動画はこちら「AWS Summit Tokyo 2017 セッション資料・動画一覧」で公開されていますので、それを見ていただくのが一番いいかなと思います。

他のAWS Summitのレポートはこちら「「 awssummit 」 一覧」も見ていただければと思います。

AWS Mobile Deep Dive – 入門から実践までの最短コース 〜 ライブコーディングで学ぶ AWS を活用したモバイルアプリの開発 〜

AWSモバイルサービスとは

  • AWS Mobile SDKをアプリから呼んで使う
  • 高品質アプリを短時間で作成出来る

Mobile Hub

  • 数少ない設定でAWSの各機能の利用がソースコード化され、プロジェクトアーカイブファイルとしてダウンロードできる
    *開発、テスト、デプロイ、分析、エンゲージの一連の流れ

Cognito

  • ユーザー管理と認証
  • デバイス間の同期

ストレージ

  • S3
  • DynamoDb

サーバーサイドロジック

  • Lambda
  • API Gateway

Device Farm

  • クラウド上の実デバイスでアプリの自動テスト
  • デバイスをブラウザ画面上で確認することも可能

SNS Mobile Push , Pinpoint

  • プッシュ通知
  • Pinpointでユーザー行動分析、エンゲージメント
  • キャンペーンのスケジューリングとPDCA

使ってみる

S3へ写真をアップロードするアプリを作る

  • Mobile Hubで設定したプロジェクトをダウンロード
  • frameworkに必要なSDKがプロジェクトに含まれる
  • 設定もプロジェクトのプロパティに入っている
  • import AWSMobileHubHelper
  • UIImagePickerController
  • 画像は入っている
  • AWSUserFileManager (S3TransferManagerよりもシンプル)

AWS Mobile SDK もさることながら、XCode便利ですなと思いました。

具現化するエンジニアリングクラウド on AWS

製造業の中でも設計、開発の分野にフォーカスした内容

シミュレーション分野でのクラウド活用

  • 時系列データの並列可視化

CAE環境を取り巻く課題

  • 年々高度化されているのでより高度なコンピューティングが求められる

物理的な制約を取り除く

  • 需要に併せてリソースの増減
  • 大量のジョブを一斉処理
  • 費用は 時間 x 台数なので1台で時間をかけて処理しても複数台で一気に処理しても同じ
  • 現在EC2では最大128vCPU , 約2TB
  • 今後も新しいインスタンスタイプが追加されると見込まれる
  • ジョブ本数を監視して計算ノードを自動で生成

AWS Batch

  • コンテナを使っている

可視化からCADへ

  • 可視化もクラウド上ですることで通信時間が増大することを防ぐ
  • WorkspacesにGPU搭載バンドルが追加
  • AppStream2.0

エンジニアリングを支えるSaaSソリューション

  • Altair HyperWorks Unlimited
  • AUTODESK A360
  • ISID PLEXUS CAE
  • Rescale

PDM on AWSによる設計コラボレーション

  • RDS : フルマネージド型データベースサービス
  • CloudFormation でオートデプロイ
  • 稼働までの時間を削減
  • グローバル展開しやすい
  • セキュリティ、コンプライアンスを強化

サーバレスで王道 Web フレームワークを使う方法

github/awslabs

  • 様々なライブラリがあるので楽しい

Express.js on Serverless

  • aws-serverless-express

始め方

  • exampleを試してみる
  • 既存のExpressプロジェクトもマイグレーションできる

動作原理

  • API Gateway Lambda Integration Proxy レスポンスヘッダをLambdaで生成

Spring Framework on Serverless

  • aws-serverless-java-container

AWS CodeStar

CI/CDパイプラインまで自動構築

  • プロジェクトを作って実行すればCloudFormationが走って実行環境が生成される
  • プロジェクトをダウンロードして編集、コミット、プッシュすればデプロイされる

サーバーレスアプリケーションのための CI/CD パイプライン構築

Serverless Application Model(SAM)

  • CloudFormationの拡張
  • 既存のFunctionをSAMテンプレートとしてエクスポート可能
  • apache2.0ライセンス
  • Lambda , API Gateway , DynamoDB , X-Rayが扱える
  • commandsにpip installが書ける

SAMとAWS Code関連とのこと連携

AWS Code Pipelineとの連携

  1. CodeCommitにpush
  2. CodePipelineが検知
  3. CodeBuildがSAMを実行
  • 実行結果はCloudWatch Logsに出力
  • Approveタスクで承認ステップを作成できる

Source

  • CodeCommit以外にもGitHub,S3を使うことも可能

build

  • CodeBuildを設定、Jenkinsや他のCIも可能
  • buildspec.yml ファイル名固定、CloudFormationコマンドを書く

修正したコードをプッシュ

  • 差分のみが実行される

AWS CodeStar

  • いくつかのガイドに従うだけでデプロイワークフローが作成できる

テストしやすいプログラム

  • 環境変数を使いハードコーディングしない
  • ログレベルも環境変数で
  • なるべくコードを変更しなくていい設計に

AWS サポートと各種運用支援ツールを利用した、システム運用・管理やコストの最適化

迅速な対応によるシステム安定運用

システムメンテナンス影響の最小化

Personal Health Dashboard
  • アカウント固有のリソースに対するメンテナンス情報、影響可能性のある障害情報の提供
  • Cloud Watch Eventと連携して、イベントに対するアクションの自動実行も可能
  • AWS Health APIでアクセス可能
  • AWS Health Tools リポジトリ(slack notifierなど)があるのでそこにあるものを使うか、手を加えて使えば楽
Service Health Dashboard
  • サービス単位のステータス表示
  • 必ずしも更新はリアルタイムではない
サポート問い合わせのベストプラクティス
  • 一つの問い合わせで関連性のない複数の質問をしない
  • 問い合わせ対象リソース所有者が起票
  • 適切な緊急度を設定
  • 調査に必要となる情報を収集しておく
AWS Support API
  • サポートの問い合わせ操作も自動化が可能
  • 問い合わせ情報をエクスポート
  • Trusted Adviserと自動連携
他にサポートに聞けること
  • サービスの仕様についての質問
  • サービス利用のベストプラクティス

AWSの利用のベストプラクティス

AWS Trusted Adviserによるセルフレビュー
  • ヘルスチェク結果の通知
  • ヘルスチェックダッシュボード
  • 通知に対する適切アクション
  • コスト最適化、セキュリティ、パフォーマンス、耐障害性など50以上のチェック項目
  • 全てのチェック項目を使うにはビジネスサポート以上が必要
AWS Trusted Adviserでまず見るポイント
  • 使用率の低いEC2インスタンス
  • アイドル状態のRDS
  • 利用頻度の低いEBSボリューム
  • セキュリティグループ設定(不要ポートのオープン)
  • S3バケット許可(意図されたパブリックアクセス)
  • IAM使用、ルートアカウントのMFA
  • AWS CloudTrailロギングの有無
  • S3バケットロギング
  • 各冗長化(RDS,ELB,VPN,,,)
  • EBSスナップショット
  • サービス制限
  • EBS プロビジョンド IOPS ボリューム アタッチ設定
  • コンテンツ配信の最適化(CloudFront)
システム品質向上のために
  • ホワイトペーパー
  • AWS Answers

コスト管理を支援する様々なツール

AWS Billing Console

  • 実績と予測
  • サービス別実績
  • 予算管理機能、予算超過通知
  • 請求レポート
  • コスト配分レポート
  • 使用状況レポート Redshiftインポート用の定義をエクスポートできる
  • Cost Explorer
  • AWS Organizationsの一括請求機能でボリュームディスカウントを受けやすくできる(EC2,RDSのリザーブドインスタンス)

DevSecOps on AWS – Policy in Code

このセッションのターゲット

基本的なAWSの機能知識のある方

DevSecOpsについて

  • ソフトウェア開発のライフサイクルでセキュリティとコンプライアンスを考えておく

Security Control

IAMロール
  • ユーザーに対してロールをアタッチ、デタッチすることで権限を変えていく
  • STS
  • Assume Roleによってクレデンシャルを生成
  • aws:RequestTag
git-secrets
  • クレデンシャルを含むコードのコミットを防止する
  • クレデンシャルを含むコードがすでに含まれていないかリポジトリをスキャンする

DevSecOpsを支えるAWSサービスインテグレーション

CloudTrail / CloudWatch Events

  • CloudTrailのON / OFFを検知
  • CloudWatchのRulesがトリガー
  • ベースラインを作って違反ユーザにポリシーをアタッチしてブロックする

Multi AccountでMulti Regionでデプロイ

  • StepFunctionで並列実行する

  • Security Automationが広範囲に実現出来る

  • Security BaselineはSecが決めるんじゃなくDev,Sec,Opsで話し合って合意して決めていく

Architecting for the Cloud -クラウドにおけるアーキテクチャの設計原則

AWSの特性

  • 即時グローバル展開
  • 最先端技術、新機能
  • サイジングからの解放
  • 可用性
  • コストメリット
  • ハイレベルマネージドサービス
  • 無制限のキャパシティ

特性を活かす設計原則

スケーラビリティ

  • 運用中のシステムの拡張/縮小
  • 柔軟性の向上、従量課金によるコスト削減
垂直スケーリング
  • スケールアップ、ダウン
  • インスタンスタイプの変更
  • リソース限界が存在
  • インスタンス停止を伴う
水平スケーリング
  • インスタンス数を増減
  • スケールアウト、イン
  • 限界は無制限
  • インスタンスは停止しない
  • ステートレスアプリケーションに保つ
  • ステートフルになる情報を外部に配置
  • 水平スケールするマネージドサービス(S3,DynamoDB,ElastiCache,,,)に配置
  • セッション情報はElastiCache , またはDynamoDB, Client-sideも検討

使い捨て可能なリソース

  • 初期費用なし、いつでも追加可能
  • 必要性に応じて増減
  • オンプレのIPアドレスのハードコード、常時電源ONなどの概念は捨てる
  • 順列のバッチスケジュールなどは一時的にリソースを増やして並列で早く終わらせる
  • イメージスナップショットを確立する(AMI戦略)
  • 全部入りAMI (変更のたびにAMI再作成
  • 部分済みAMI(頻繁にコードに変更が入るなど,起動時に変更部分の最新バージョンを取得)
  • 最小構成AMI (起動時の処理が増えるので起動に時間がかかる)
  • 自動化によりオペミス削減、可用性向上
  • CloudWatch + AutoScalling + ALBで自動水平スケール

疎結合

  • 結合度は低いほど望ましい(スケーリングしやすい、不具合影響を最小限)
  • アクセス元から見てアクセス先をブラックボックスにする(レスポンスで返すものだけ見せる)
  • Service Discovery
  • 例 アプリサーバとWebサーバのインターフェースをELBのみとする
Asynchroninous Integration
  • 同期処理である必要がなければ非同期にする
  • SQS,Kinesis,Lambda,SWF,,,,,,,
  • 例 : SQSのキューを介してフロントエンドからの指示をバックエンドが処理する
Graceful Failure
  • 安全に落とす
  • リトライ

サーバではなくサービスの利用

  • マネージドサービスを利用して運用と責任を軽減する
責任共有モデル
  • Infrastructure Service ハードまでをAWS
  • Container Service アプリケーションまでをAWS
  • Abstracted Service

データベースの使い分け

  • DynamoDB SSD永続化、レプリケーション
  • ElastiCache 低レイテンシー
  • RDS RDB
  • Redshift DWH

単一障害点の排除

  • マルチAZ
  • 堅牢なデータストレージ
  • 疎結合な構成による障害分離

コスト最適化

  • オーバープロビジョニングの回避(常にピークに向けた構成である必要はない)
  • 継続的な監視(CloudWatch,TrustedAdviser)
  • 伸縮自在性を利用
  • 適切な購入オプション(RI,,,,)

キャッシュの利用

  • 性能向上
  • ElastiCache
  • CloudFront

セキュリティ

  • 全てのレイヤーでセキュリティを意識する
  • リアルタイム監査
  • Security as Code
  • 最小情報の原則

AWS の NoSQL 入門 〜Amazon ElastiCache, Amazon DynamoDB〜

NoSQLとは

  • 非正規化、階層化
  • 高速なパフォーマンス
  • 高いスケーラビリティ
  • ユースケースに応じた形式
  • トランザクション処理は苦手
  • クラスタの運用負荷が高い
  • トランザクション処理が必要なものはRDBMSを使って、スケールが必要なデータはDynamoDBなどデータ種類によって使い分ける

キーバリューストア

  • キーとバリューの単純構造
  • 高速なパフォーマンスが出せる
  • リッチなデータ構造は取りづらい
  • rediscover,memcache

カラム指向データベース

  • ログなどに向く
  • カラム型データベース

ドキュメント指向データベース

  • キーとオブジェクト(Json,XML)
  • mongodb

グラフ指向データベース

  • データ同士の関係をグラフという形で表す
  • 複雑な関係を表すことを得意とする

Amazon ElastiCache

  • キーバリュー
  • memcached,redisをマネージドサービスで提供
  • スナップショットバックアップ(S3)、各対して1つのスナップショットまで無料
  • 自動障害検知、自動マスタ復旧
  • ElastiCche間のAZ間通信は無料
  • 単純な計算が必要なデータをキャッシュ

memcached

  • マルチスレッド
  • 非永続化、再起動で消える
  • メンテナンスが楽
  • 垂直分散が楽

redis

  • シングルスレッド
  • 永続化
  • 多数のデータタイプ
  • Atomic処理
  • リードレプリカ/フェイルオーバー
  • pub/sub メッセージング
  • Redisクラスタのサポート

Amazon DynamoDB

  • キーバリュー、グラフ指向、ドキュメント指向にも対応
  • イベント指向のプログラミングが可能
  • データは3AZ
  • テーブルごとにRead/Writeのスループットキャパシティを割り当てる、オンラインで変更可能
  • ユーザの需要にあわせてキャパシティをスケール
  • ストレージの容量制限がない、従量課金
  • パーティションキー、ソートキーを決める
  • Stream処理で非同期処理、イベント駆動が可能
  • グローバルアプリケーション
  • 継続的な機能追加
  • 一定期間を過ぎたアイテムを非同期に削除
  • VPCエンドポイント(パブリックベータ)
  • DAX(パブリックベータ)
  • プロビジョンドスループットによる時間単位の従量課金とキャパシティユニットの課金
  • 例 1KB以下、1ヶ月で100万回づつ読み書き、1TB保存で月約11ドル
  • ユーザー行動履歴、ソーシャルアプリのバックエンドなど

AWS で実現するセキュリティ・オートメーション

オートメーションは戦略策定の礎

  • 自動化目的 コスト削減、スピード向上、生産性向上、ミス
  • 効率化だけではない価値がある
  • セールスフォースオートメーション : 営業プロセスの効率化によって集まったデータにより様々な分析ができるようになり営業活動に革新が起こる
  • 「やること」と「やらないこと」を決められる=戦略
  • 多種多様なデータ集約、可視化と効果測定、分析による意思決定、これらのプロセスの土台がオートメーション

セキュリティ・オートメーションを前提に設計されたAWSサービス

サービスのキュリティ対策の分類

  • 対策主体による分類(人、組織、技術)
  • 対策対象による分類(サーバ、ネットワーク)
  • 対策場所による分類(入口,出口)

適応型セキュリティアーキテクチャ

  • 防御 (従来のセキュリティ対策、標的型攻撃の台頭により100%は防げない)
  • 検知(誤検知、検知漏れを少なくしなければならない、相関分析、重要度、優先度付けが必要)
  • 対応 (一時対応のスピードが必要、恒久的な対応も必要)
  • 予想(異常に気づくための定常状態の把握、次の防御策を選択するためのリスク分析)
  • 継続的な監視と分析

AWSサービスのマッピング

  • 防御(CloudFront,WAF,SG,NACL,,,,,)
  • 検知(AutoSchelling,VPC Flow Logs,,,,,)
  • 対応(Lambda,SNS,,,)
  • 予想(Inspector,,)
  • 監視と分析(CloudWatch,,,)

  • IPブラックリストをWAFへ自動定期反映 リストは外部から取得
  • スケールアウトによる問題の抑制と通知
  • 端末自動管理とバックアップ

セキュリティ戦略基盤となるAWSクラウド環境

  • VPC Flow Logs + ElasticSearch + kibanaによるセキュリティダッシュボードを可視化
  • WAF + Machine Learning + DGA Protection

リスクベースのセキュリティ戦略

  • 脅威分析 異常検知、ヒューリスティック分析、脅威インテリジェンス
  • 脆弱性分析、脆弱性スキャン、ベンチマーク評価
  • 情報資産分析

Amazon EC2 Systems Managerによるハイブリッド環境の管理

Amazon EC2 System Managerとは

  • Windows,Linuxに対して自動構成と継続的管理
  • EC2だけではなくオンプレミスも対象

構成要素

  • Run Command 管理タスクを実行
  • State Manager
  • Inventory 情報収集
  • Patch Manager パッチ適用
  • Automation イメージ取得など自動化
  • Maintenance Window メンテナンススケジュールなど管理
  • Parameter Store パラメータを保存

前提条件

  • APIにアクセスするためにインターネットに接続できる事

利用シナリオ

Run Command

  • リモートから任意のコマンドを実行
  • Jsonベースのドキュメントでコマンドを定義
  • 実行結果はS3
  • 通知はSNS
  • インスタンスのエージェントが動くのでSSH,RDPを閉じてても良し

SSM Agent

  • インストールタイプのエージェント
  • オープンソース、githubで公開
  • EC2 Windowsにはあらかじめインストール済み

State Manager

  • OSとアプリケーションの設定を定義、状態を維持

パッチ管理

  • ベースラインを定義してWindowsのパッチを適用
  • Patch Baselineでカスタムパッチポリシーを定義(適用先グループはここで定義)
  • Maintenance Windowで適用時間を設定
  • Patch BaselineとMaintenance Windowsを関連付ける

Automation

  • Jsonベースのドキュメントでワークフローを定義
  • Run commandとLambda関数をサポート
  • 起動、停止、AMIを作成など
  • インプット、アウトプットパラメータを設定できる
  • 実行結果はCloudWatch Eventsから通知可能

Parameter Store

  • RunCommand,StateManager,Automation他、外部アプリケーションからも使用可能

料金

  • EC2 System Manager自体の使用料金は無料

全部教えます!サーバレスアプリのアンチパターンとチューニング

Lambda 関数のパフォーマンス(遅い原因)

プログラムの問題

ロジックそのものの問題
  • コードの最適化
  • 各言語のベストプラクティス

コンピューティングリソースの問題

メモリ設定
  • メモリサイズと比例してCPU能力も割り当てられる
  • 処理時間が短縮できるのであればメモリ設定を増やした方がコストは変わらない

コールドスタート

Lambda関数が起動するプロセス(コールドスタート)
  1. ENIの作成 (VPC内のみ , 10~30秒)
  2. コンテナの作成
  3. デプロイパッケージのロード
  4. デプロイパッケージの展開
  5. ランタイム起動、初期化
  6. 関数メソッドの実行(Duratonの対象)
ウォームスタート
  • 再利用出来るコンテナがある
  • 安定的にリクエストが来ている状態
  • しかしコールドスタートを許容できないのであればそのシステムにとってLambdaの選択は正解ではない
コールドスタートを速くする方法
  • メモリ設定をあげる
  • ランタイムを変える(JVMは遅い)
  • ただしウォームスタートはコンパイル言語の方が早い傾向
  • パッケージサイズを小さくする、不要なコードを減らす
  • 依存関係を減らす、不要なモジュールは含めない
  • VPCは必要でない限り使用しない
  • 同期実行が必要な箇所ではなるべく使わない
  • なるべく非同期に設計する(DynamoDB StreamsとLambdaなど)
  • Javaの場合、POJOでなくバイトストリームを使う
  • Python 初期化処理はハンドラの外ではなく、遅延ロードを使う

アーキテクチャの問題

  • 同時実行数に引っかからないようにする
  • 出来るだけ非同期でInvokeする
  • レスポンスを待つ必要がなければ非同期
  • API Gateway ->Lambda でPUT系の処理はLambdaで直接処理するのではなく、SQSkinesisに処理を流してそこからLambdaを発火して本処理をする
  • GETなどレスポンスをリターンする処理は致し方ない
  • いかに並列処理を行うか考える
  • 1つのLambda関数でループするのではなくループ回数分Lambda関数を実行する

同時実行数

  • 平均実行時間 * 秒間リクエスト数
  • 上限1,000
  • ストリームベースの場合はシャードを増やす

アンチパターン

RDBMSを使う問題

  • DynamoDBを推奨
  • RDBMS側のコネクション数がスケール出来ない

IP固定したがり問題

  • 証明書や認証で対応する

サーバーレス夢見がち問題

  • 運用、監視は必要
  • CloudWatchのメトリクス、カスタムメトリクス、Logsへの出力
  • 複雑な処理では開発コストが上がる可能性
  • 障害発生を前提として実装
  • 1回しか実行しないということは保証していない

[ワークスアプリケーションズ] AWS Lambda で変わるバッチの世界 ~ CPU 時間トータル 100 時間の処理を 10 分で終わらせるには~

対象処理

  • 画面の高速描画のための前処理
  • 画面総数 9000弱
  • CPU時間 100時間の処理
  • 目標時間10分

AWS Lambda採用

採用理由

  • スケーリング管理コスト0
  • インスタンス管理コスト0
  • 100ms単位の課金

フロー

  1. 画面リスト作成
  2. HTML最適化
  3. JSコンパイル
  4. CSSコンパイル

一回のフローは10分

処理の分割化

  • フローのそれぞれの処理をLambda Functionにした

実行

  • 起動用ファイルをS3に置くとLambdaが発火
  • ステータス管理用ファイルをS3に作る

Troubleshooting

  • 速度が思ったより速くない
    CPU性能はメモリ設定に比例するので上限を上げた。
    速く終わるのでコスト増はほぼなかった。
  • 並列数が伸びない
    VPCの設定を見直し
    不要な処理でVPCを外した
  • 起動直後エラーになってしまう場合がある
    S3オブジェクト確認
  • S3イベントが登録されない、登録したはずが消えている
    一度に全てのイベントを登録するよう改修
  • 想定金額の5,6倍のコスト
    ローカルファイルを都度cleanする

今後の課題

  • DBが高負荷
  • Step Functionの検証

Amazon EC2 Performance Deep Dive

EC2インスタンスリソースによる性能要素

インスタンスファミリー

  • 汎用
  • コンピューティング最適化
  • ストレージI/O最適化
  • メモリ最適化
  • GPU,FPGAアクセラレーテッド

インスタンスサイズ

  • Dedicated Hostsで検索

物理リソースの配分

  • オーバーコミットはしていない
  • 同居する他のインスタンスには影響しない

vCPU(Virtual CPU)

  • ハイパースレッド論理コアの数
  • 2で割った数が物理CPUコア数
  • ハイパースレッドはLinuxの場合、無効化できる
  • P-stateとC-Stateの制御
  • NUMA

I/O関連のパフォーマンスオプション

ストレージ関連

EBS最適化
  • 独立した帯域を確保しI/O性能の安定化
  • EBSはネットワーク接続型ストレージ
  • 特別な理由がなければ有効にする

インスタンスストア

  • EC2ローカルのディスク

ネットワーク関連

  • インスタンスサイズによって性能が変わる

拡張ネットワーキング

  • インスタンス対応によって変わる
  • 対応するドライバのインストールが必要
  • 属性をつけて指定する

プレイスメントグループ

  • インスタンス間通信を最適化するオプション

パフォーマンスクレジット

t2インスタンス

  • CPUクレジットによりバーストする

EBSボリュームのクレジット

  • ボリュームI/Oクレジット
  • スループットクレジット

R4インスタンスの通信帯域クレジット

その他のパフォーマンス要素

時刻情報

  • TSCクロックソース
@yamamanx

開発ベンダー5年、ユーザ企業システム部門通算9年、ITトレーナー1年目のSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。

このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。

また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。

 - AWS, study ,

ad

ad

  関連記事

「kintone Café 大阪 Vol.14 〜モザイクなし!うちのkintoneはこれだ!〜」で登壇しました

「kintone Café 大阪 Vol.14 〜モザイクなし!うちのkinto …

Microsoft TeamsのIncoming Webhooksを使ってAWS Lambda(Python)からFeedlyの記事を自動投稿する

Microsoft Teamsの検証を始めましたので、Slackで自動化している …

Developers Summit 2018 「「技術内閣制度」2年間やってきて得られた事とこれから ~開発チーム横断での技術課題解決、技術力強化、エンジニア文化醸成」を聞きました

以下は、思ったことや気になったことをメモしていますので、必ずしも登壇者の発表内容 …

Amazon Elasticsearch ServiceにMySQLのデータを投入してkibanaで可視化してみる

MySQLのデータの可視化にAmazon Elasticsearch Servi …

AWS EC2 インスタンスステータスのチェックで失敗して起動しなくなり復旧

EC2のインスタンスに接続出来なくなったので、AMIから作成してElastic …

AlexaにAWSの最新Feedを読み上げてもらう(Lambda Python)

年末にAmazon Echo Dotを購入しましたので、練習がてらAlexaスキ …

Innovation EGG 第8回 『可視化・課題と支える技術』に行ってきました

Innovation EGG 第8回 『可視化・課題と支える技術』に行ってきまし …

Feedlyのフィードを自動でSlackへ投稿する(AWS Lambda , Amazon DynamoDB)

やりたいこと Feedlyで共有したいフィードに特定のタグを付けます。 特定のタ …

Alexa Day 2018で「Alexa and Machine Learning on AWS」を聞きました

Photo by 金春さん 20180211 alexa day 2018 Al …

Route53でドメインを新規取得してDNSレコードを設定する

Elastic IPをAWSで発行しているのですから、DNSの設定も同じようにマ …