20191127のAWSに関する記事は21件です。

WordPressを利用したハンズオン形式のAWS学習書籍 HTTP 500エラーでWelcomeページが見られない

結論:PHPのバージョンアップが必要だった

以下、全てWebサーバーとして利用する想定のAWS EC2内でのコマンド。
書籍内の手順通りにPHPのインストールをした場合はまず既存PHP及びモジュール削除。

#利用中のモジュールを確認
$ yum list installed | grep php
php.x86_64                            5.4.16-45.el7                    @base
php-cli.x86_64                        5.4.16-45.el7                    @base
php-common.x86_64                     5.4.16-45.el7                    @base

#消去
$ sudo yum erase -y php-common php-cli php

#upgrade
$ sudo yum upgrade

Remi’s RPM repository追加して、PHP71とモジュールをインストール

特に「php71-php」をインストールしないと、ApacheがPHPを読んでくれなかったのでハマった。

#これをしないとRemi’s RPM repositoryがインストールできない
$ sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

#Remi’s RPM repositoryのインストール
$ sudo yum install -y https://rpms.remirepo.net/enterprise/remi-release-7.rpm

#PHP71及び(書籍指定の)必要なモジュールをインストール
$ sudo yum install -y php71 php71-php php71-php-cli php71-php-common

#Apache再起動
$ systemctl restart httpd

書籍内で必要とされているモジュール(旧PHP)で、PHP71対応モジュールについては要Google先生。
これでWordPressのウェルカムページを見ることができるはず。
あまり覚えてないけど体感3日はハマった。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS SES + Google Domains でメール送信してみた

概要

本投稿は「AWS SES」をちょっと試してみたい人用です

AWSにはSES(Simple Email Service)というメール送信サービスがあります。
Webサービスに使うアラートメールとかに重宝しますし、設定も簡単なのでとても便利だと思います。

実際に使うかどうかは置いといて、
簡単に設定できるので、ハンズオン的にまとめてみました。

目標 : AWS SES を使ってテストメールが送れるので、送信できるところまで試してみます。
所要時間 : 1時間(内待ち時間30分) ぐらい。

始める前に、次のものをご準備ください。

準備するもの

AWS SES を開く

  • まずは、AWS SES を開きます。以下のURLにアクセスします。
     https://console.aws.amazon.com/ses/home

  • リージョンを選択
     東京リージョンは対応していないので、米国東部(バージニア北部)などを選択します。

ドメインを登録

  • ドメインを登録します。
     このドメインは、送信メールアドレスに使用します。

■ AWS SES コンソール画面
Untitled.png
 ① Domains を選択します。
 ② Verify a New Domain を選択します。

■ ドメイン登録画面
Untitled.png
 ① Domain にドメインを入力します。(例)example.com
 ② Generate DKIM Settings にチェックを入れます。
 ③ Verify This Domain ボタンを選択します。

DKIM(DomainKeys Idetified Mail)は、電子メールにおける送信ドメイン認証技術の一つです。
( 参考: https://www.nic.ad.jp/ja/basics/terms/dkim.html

  • 次のような画面が出ますが、すぐに閉じないでください。

■ DNSレコード設定情報
Untitled.png
 ① Download Record Set as CSV を選択して、CSVファイルをダウンロードします。

DNS設定

DNSレコード情報を DNS に設定します。
先ほど取得したCSVファイルに、設定する情報が記載されています。

本投稿では Google Domains を使用して説明しますが、
やり方はどのドメイン会社もほとんど一緒です。

■ DNSレコード設定画面
Untitled.png
 ① DNS を選択します。
 ② CSVファイルを参考に、レコードを追加していきます。
 黒塗りばっかりになってしまった...

DNS認証の確認

■ 未認証の状態
Untitled.png

■ 認証済みの状態
Untitled.png
 ① Verification Status が 「verified」 になっているのを確認します。
   DNSの設定をしてから、少し時間がかかります。

メールアドレス認証

  • メールアドレスを登録します。
    ここで登録するメールアドレスは、送信先として許可するメールアドレスです。

AWS SES では、許可した送信先にしかメールを送信できません。
送信先制限の解除も出来ますが、本投稿での説明は省きます。

■ AWS SES コンソール画面
Untitled.png
 ① Email Addresses を選択します。
 ② Verify a New Email Address を選択します。

■ メールアドレス登録画面
Untitled.png
 ① Email Address にメールアドレスを入力します。(例)example@gmail.com
 ② Verify This Email Address ボタンを選択します。

  • 登録したメールアドレスにメールを送った旨のメッセージが表示されますが、そのまま閉じます。
  • Gmailなどの受信トレイを確認します。

■ AWSからの受信メール
Untitled.png

  • リンクをクリックします。
  • 「検証に成功しました」というメッセージが書かれたページが表示されます。

送信テスト

設定が完了したので、メールを送信してみます。

  • 送信メールを作成します。

■ AWS SES 画面 (Domains)
Untitled.png
 ① Domains を選択します。
 ② 対象のドメインにチェックを入れます。
 ③ Send a Test Email を選択します。

■ 送信メール作成画面
Untitled.png
 ① メールを作成します。
  FromはなんでもOKです。Toには必ず認証したメールアドレスを入力してください。
 ② Send Test Email を選択します。

  • Gmailなどの受信トレイを確認します。
  • 作成したメールが受信出来ていればOKです!

お疲れさまでした:grinning:

お掃除(任意)

設定した内容を削除するまでが、ハンズオンです。(削除するかどうか自由です。)

AWS SES

  • Domains から削除
  • Mail Addresses から削除

Google Domains

  • 設定したDNSレコードを削除

最後に

AWS SES と仲良くなれましたでしょうか。
WEBアプリの運用に AWS SES を採用したことがありますが、とても手軽に実装できました。
運用中のバウンスメールには頭を悩まされましたが。。

AWSにはいろんなサービスがあるので、じゃんじゃん使っていきましょう!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Laravel6.5でFormファザードを利用する

Laravel6.5.3でFormファザードが使えるようにする

以下のコマンドを実行するだけ。(バージョン指定せずに自動でインストールしてくれるっぽい)

ターミナル
$ composer require laravelcollective/html
実行結果
Using version ^6.0 for laravelcollective/html
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Installing laravelcollective/html (v6.0.3): Loading from cache
Writing lock file
Generating optimized autoload files
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> @php artisan package:discover --ansi
Discovered Package: facade/ignition
Discovered Package: fideloper/proxy
Discovered Package: laravel/tinker
Discovered Package: laravel/ui
Discovered Package: laravelcollective/html
Discovered Package: nesbot/carbon
Discovered Package: nunomaduro/collision
Package manifest generated successfully.

無事インストール完了。

ネットで調べると大体、ComposerとLaravelのバージョンの相性の善し悪しがあり、
バージョンまで指定してコマンドを実行していたので、
それに倣って試行錯誤してみましたが、なかなか進みませんでした。

自分でバージョン指定せずにコマンドを実行してみたら、うまくいきました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Datadog × AWS を初めた話

Ateam Lifestyle Advent Calendar 2019の4日目は、株式会社エイチームライフスタイル 名古屋開発部第1の(希少な)インフラエンジニア山口(@dayamaguchi1)が努めます。
Qiita初投稿ですが、特に緊張せず背伸びせず緩やかにやっていきます。

はじめに

弊社では最近、監視ソリューションであるDatadogを利用し始めました。
スモールスタートで実機検証段階ではありますが、担当している私個人としてはもっと拡大していき、より強固な監視基盤を構築したいと思っています。
(反面、コストがいくらかかるか毎日ビクビクしてます。従量課金コワイ)
Getting Startと被りに被ってしまっているのですが、実際に導入した体験談を加味して提供しますので、この先始める方の踏み台にでもなれば幸いです。

先にまとめる

  • DatadogのAWSインテグレーション使うと、ELBやRDSと言ったマネージドサービスは概ねタダで監視できるぞ!
  • AWS Systems Manager使うと楽にDatadog
  • Agentがインストールできるよ!
  • EC2使うならSSM Agent入れておくとあとで運用が楽になるぞ!

Datadog導入前夜

Zabbixの終焉(嘘ですまだ使ってます)

Datadog以前の監視基盤は基本的にZabbixオンリーでした。
またZabbix Serverはエイチームグループ全体で管理されており、ライフスタイルの一担当者にすぎない私では、サーバの設定変更やプラグイン追加、バージョンアップなどが気楽に行えない状態でした。
Zabbixのバージョンアップなども実施していますが、コンテナ化している環境も増えており、現在の環境により適した監視ソリューションを選択する必要がありました。

AWSをもっと監視したい願望を叶える

Datadogは各種IaaSとの連携機能が豊富です。
弊社では主にAWSを活用しており、AWSはその高機能さから大量の情報を所有しています。CloudTrailやVPC Flow Logなどがその代表ですね、
ただ大量すぎてみるのも辛い。
とはいえ、AWSを活用していく上で、DatadogがもつAWSインテグレーション機能はとても魅力的に見えました。

またライフスタイルでは複数の事業が横断的に稼働していることもあり、事業ごとにAWS費用が幾ら発生しているか確認する必要があります。
そのため、AWSオーガナイゼーションを活用してAWSアカウント分離をしています。
ただしアカウント分離の弊害として、横断的に監視をすることが難しくなってしまいました。
そこで颯爽登場したのがDatadog。これで集約し、監視基盤を作ってやろうと野望を抱きました。
まだ抱いただけなので、俺の戦いはこれからだ。
山口の今後の展望にご期待ください。

Datadog導入最前線

ついにAWSへ導入を進めます。

AWSインテグレーションから始めよう

まずはDatadogのインテグレーション機能を使って、AWSアカウントを丸ごとDatadogと連携させます。
これは公式ドキュメントが手取り足取り丁寧なので、わざわざ解説はしません。
以下をご参照ください。
Datadog Docs - Integragion - AWS

私が導入時に気にしたポイントだけ簡単にあげておきます。

  • EC2を対象にすると1台あたりのコストが発生するので、Datadogが参照するEC2は特定のタグがあるものだけにする
    • AWS Integrationにある「Optionally limit resource collection」-「to hosts with tag:」で、Datadogが参照するEC2を選択することが可能
      • 弊社では「Tag:Datadog,Value:on」となっているEC2のみ対象になるように設定
    • タグの設定をする場合は、タグエディターを使うとまとめて設定できるので、活用しよう
  • ELB、RDSなどのマネージドサービスを監視するのはタダ!AWSインテグレーションしない選択肢はないぞ
    • lambdaとかお金かかるのもあるから、pricing見たりDatadog営業の方に相談してね

Datadog Agent Install!!

EC2の(というかLinuxOSの)詳細な情報を取得するためにはDatadogAgentを導入するのが最適です。
導入しないとCloudWatchのEC2メトリクスしか取得できないので、あまり旨みがありません。
メモリのメトリクス見たいですよね?私は見たい。
どうでEC2を対象にしたら1台あたりのコストが発生するので、DatadogAgentを入れてしまいましょう。

EC2にDatadogAgentをInstallする

LinuxOSへのDatadogAfgent InstallはOSにログインしてコマンド入力一発で完了します。
環境固有の値はマスクしますが、LinuxOSであれば以下のようなコマンドになります。

DD_API_KEY=**************** bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/datadog-agent/master/cmd/agent/install_script.sh)"

コマンドの内容はDatadogのコンソールに記載されているので、そちらを参照ください。

ただコマンド1つとはいえ、サーバ台数が複数台に渡ると大変です。
1回1分の作業としても、100台あればすごい辛いです。
そこで登場するのがAWS Systems Managerです。

Systems ManagerのRun Commandを活用

Systems ManagerはAWSを管理する上で多数の機能を保持していますが、今回はRun Commandを使います。
 ※Systems Managerを利用するには対象EC2にSSM Agentがインストールしてあることが前提です。Systems Managerは超有能なのでSSM Agentは積極的に導入しましょう!!!!!

監視対象のEC2には「Datadog:on」のタグが設定されているので、以下の流れで実施しました。
(簡単なのでちゃんと検証してください。いきなり本番実行とかやめようね。)

  1. Systems ManagerコンソールからRun Command(コマンドの実行)を選択
  2. コマンドドキュメントの中から、AWS-RunShellScriptを選択
  3. コマンドパラメータに、Datadog Agent Install用のコマンドを入力(細かい条件分岐なんて考えない)
  4. ターゲットに「Specify instance tags」を選択し、「Datadog:on」というタグを対象にする
  5. Run Command実行
  6. Run Commandの実行が正常終了することを確認
  7. 少し待つと、Datadog Console上にEC2が追加されているに違いない未来が待っている

とっても簡単。ありがとうSystems Manager。

Datadog導入期の終わり

DatadogAgentを入れただけでできることは、OSの情報を吸い上げることだけです。
M/Wの情報が必要な場合は、個別でDatadogのインテグレーション機能を活用してDatadog Agentのconfを設定する必要があります。
NginxやApacheと言ったWebサーバを含め、それぞれのM/Wごとにインテグレーション方法が異なるため、この記事では割愛させていただきます。
私もこれからなので、そんな装備では大丈夫ではない状態です。
Datadog設定期がこれから始まるのです。

今後の展望

今後やりたいことは以下です。思いつきで書いたのでもっとたくさんあると思います。
とにかくDatadog見て今まで見てこれなかった(見てこなかった)データを可視化していきたいですね。

  • 利用しているM/Wのメトリクスを取得する
  • 各種モニターを整備し、サーバダウン時に検知する仕組みを導入
  • syntheticsを活用した簡単なE2Eテスト
  • Networkを利用したネットワーク経路の把握(まだ出たての機能なのであまり充実していません。これからに期待)
  • etc...

さいごに

Ateam Lifestyle Advent Calendar 2019 の 5日目は、@yuko1658 がお送りします。弊社の機械学習プロフェッショナルです!今度お酒飲みに行きましょう。(私信)

そんな"挑戦"を大事にするエイチームグループでは、一緒に働けるチャレンジ精神旺盛な仲間を募集しています。興味を持たれた方はぜひエイチームグループ採用サイトを御覧ください。
https://www.a-tm.co.jp/recruit/

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Laravel6.5 ログイン(login)画面と登録画面(register)画面のレイアウトの崩れを修正

ログイン画面と登録(register)画面のレイアウト崩れをただす方法

Laravelをインストールして、いざ開発してみようとしたらレイアウトが崩れてる。。。
login.png

開発環境
・AWS Cloud9
・PHP 7.3.11
・Laravel6.5

Laravelのインストール後、

ターミナル
$ composer require laravel/ui
ターミナル
$ php artisan ui vue --auth

$ php artisan migrate
ターミナル
$ npm install
npm WARN deprecated fsevents@1.2.9: One of your dependencies needs to upgrade to fsevents v2: 1) Proper nodejs v10+ support 2) No more fetching binaries from AWS, smaller package size
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.9 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.9: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

added 1011 packages from 489 contributors and audited 17168 packages in 26.202s
found 0 vulnerabilities

LaravelはCSS/JavaScriptのファイルをコンパイルする必要があります。

ターミナル
$ npm run dev

> @ dev /home/ec2-user/environment/instaAutoPost
> npm run development


> @ development /home/ec2-user/environment/instaAutoPost
> cross-env NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js

12% building 20/23 modules 3 active ...t/node_modules/jquery/dist/jquery.js

npm run dev.png

こんな感じで出たら無事、ビルド終わりです。
login success.png

ちゃんと表示されました。

参考ページ
Laravel6.0「make:Auth」が無くなった 〜Laravel6.0でのLogin機能の実装方法〜MyMemo

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS CodePipelineを通すとsymlinkがテキストファイルになる件

はじめに

AWS CodePipelineでは、

  1. Source

  2. Build

  3. Deploy

の3ステージでCI/CDパイプラインを実行します。

上記のSourceステージのリポジトリにsymlinkがあった場合、それらはBuildステージの段階でただのテキストファイルに変化してしまうようです。

Sourceステージでの状態

以下は、Sourceステージ(CodeCommitあるいはGitHubリポジトリ)での状態です。
この段階ではsymlinkとなっています。

$ ls -l
-rw-r--r--  1 foo  bar  193 Nov 27 19:10 appspec.yml
-rw-r--r--  1 foo  bar    0 Nov 27 19:10 blank.txt
-rw-r--r--  1 foo  bar  108 Nov 27 19:10 buildspec.yml
lrwxr-xr-x  1 foo  bar    9 Nov 27 19:10 symlink.txt -> blank.txt # symlinkになっている

Buildステージでの状態

次に、Buildステージでの状態を見てみます。

具体的にはマネジメントコンソールのCodeBuildの画面での、このファイルです。
Sourceステージのリポジトリの特定のブランチ・コミットが、ZIPに固められてS3にアップロードされたもの、という理解です。

スクリーンショット 2019-11-27 19.57.45.png

これをダウンロードして中身を見てみると、以下の通りsymlinkでは無くなっています。

$ ls -l
-rw-rw-r--  1 foo  bar  193 11 27 10:01 appspec.yml
-rw-rw-r--  1 foo  bar    0 11 27 10:01 blank.txt
-rw-rw-r--  1 foo  bar  108 11 27 10:01 buildspec.yml
-rwxrwxrwx  1 foo  bar    9 11 27 10:01 symlink.txt # symlinkではなくなっている

symlink.txtの中身は以下のようなテキストファイルになっています

symlink.txt
blank.txt

最後に

CodePipelineの仕様?なんでしょうか。

CodePipelineを使っていて、気になった点でした。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Rekognition デモまとめ

目的

前回の投稿でMLの動画解析ソリューションを調べました。
機械学習関連AWSソリューション簡易まとめ

今回は実際にRekognitionのデモを体験したので、
スクショを貼って具体のイメージが持てる状態にしたいです。


オブジェクトとシーンの検出

画像に現れるオブジェクト検出を行います。自分の画像で解析してみましたが、オブジェクトは汎用的なものが多く精度はデモ画像ほど検出してくれませんでした。動画を検索する際のキーワード抽出等で活用できるかもしれません。
image.png


画像の節度

サービスを提供する側にとって、不適切な画像などは検知したい場合があると思います。家族の画像の場合は問題ないですが、水着の女性の画像はSuggestiveと判定されています。この判定がされた場合に映像の検品などのユースケースがあると思います。
image.png


顔の分析

笑っているなど、顔の情報が取得できます。複数人いる場合もそれぞれ検出してくれます。自分の画像で試してもかなりの精度でした(99%の確率で幸せとのこと笑)。動画を検索する際のキーワード抽出等で活用できるかもしれません。
image.png


有名人の認識

日本人かつ複数人の有名人が写る画像でもちゃんと判定してくれました(沢尻エリカはiconiqと誤判定された)。たまたま目に止まったbishというバンドメンバーでは判定できませんでした。動画を検索する際のキーワード抽出等で活用できるかもしれません。
image.png


顔の比較

そのままの機能ですが、自分の画像で試してみたところかなりの精度で検出してくれました。動画のグルーピングに活用できそうです。
image.png


イメージ内のテキスト

いわゆるOCRです。デモのためなのかわかりませんが、日本語は対応してないようでした。
image.png


ビデオ分析

ビデオ分析では今まま説明した機能が入っていました。動画のプレビューにあるオレンジの帯は選択した人物やオブジェクトの出現時間となります。利用してみましたが、オブジェクトの出現時間の精度がいまいちのようでした。
image.png


まとめ

Rekognitionでは人物検出など既に実用できるレベルでした。懸念があるのはオブジェクト検出です。そもそもオブジェクト検出は膨大な種類から特定する難しい問題だとは思います。そのため用途を限定する必要があると感じました。Rekognitionの概要は掴めたので、次はAzureのVideo indexerを利用してみたいと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon Comprehend を利用した口コミの感情分析

はじめに

今回は AWS の提供する自然言語処理(NLP)サービス Amazon Comprehend を利用して文章の感情分析を行います。

弊社の運営する スクール検索口コミサイト の口コミを利用して感情分析を行い、弊社の口コミサイトの現状を確認してみようと思います。

Amazon Comprehend とは

AWS の提供する自然言語処理(NLP)サービスです。文章を入力として与えることで、エンティティやキーフレーズ、主要言語の検出ができたり、感情分析や構文分析、トピックモデリングができます。
また、AutoMLを利用することで、自然言語処理の専門知識なしでカスタムモデルが作成でき、文章を独自のカテゴリに分類したり、特定の用語や名詞ベースでのエンティティ抽出が行えます。

https://aws.amazon.com/jp/comprehend/

こちらでは、AWS Comprehend の利用例が記述されています。
※英語のため、Google のページ翻訳を用いて読むことをお勧めします。

2019年11月7日に日本語対応となったためご紹介いたします。

今回やること

弊社の運営する、スクール検索口コミサイトの口コミ感情分析を行います。

運営する口コミサイトが現状どのような場として利用されているのか、口コミの感情から傾向を読み取ろうと考え、検証に至りました。

データの準備

解析したい文書を1行ごとにテキストファイルに追加します.
口コミサイトより、約4万6千件の口コミを入手し、各口コミを1行ごとに追加しました。

※1行当たり5120バイトまでという制限があります。

image.png

データを S3 にアップロード

Amazon Comprehend は日本語対応したものの、まだ東京リージョンでは扱えないため、連携する S3 バケットを Amazon Comprehend で利用できるリージョンで作成する必要があります。

以下に Amazon Comprehend が対応しているリージョンを示します。

対応リージョン
欧州(ロンドン)
欧州(アイルランド)
アジアパシフィック(シンガポール)
アジアパシフィック(シドニー)
欧州(フランクフルト)
米国東部(バージニア北部)
米国東部(オハイオ)
カナダ(中部)
米国西部(オレゴン)
※2019/11/27時点

  • s3 バケットを対応リージョンで作成します。
    image.png

  • 作成したバケットの任意の場所に、文章データをアップロードします。
    image.png

Amazon Comprehend で 感情分析

  • s3 バケットを作成したリージョンにいることを確認し、Amazon Comprehend を開きます。
    image.png

  • Launch Amazon Comprehend クリックします。
    image.png

  • サイドバーから Analysis jobs を選択し、Create job をクリックします。
    image.png

  • Name : 任意のジョブ名を付けます。

  • Analysis type : 分析に利用するタイプを選択します。今回は感情分析をおこなうため、Sentiment を選択します。

  • Language : 解析する文章の言語を指定します。

image.png

  • Data source : 利用するデータソースを選択します。
  • S3 location : 入力データの保存先を指定します。
  • Input format : 入力データのフォーマットを選択します。今回は1ファイルの各行に文章を保存したため、 One document per line を選択します。

image.png

  • S3 location : 以下に出力先 s3 パスを入力します。
    image.png

  • 作成した s3 バケットへの入力、出力を許可するロールを選択してください。

image.png

  • Create job をクリックします。

image.png

  • ジョブを作成したら、Status が Completed になるまで待ちます。
  • 6722465文字のデータに対して、7分ほどで解析は終了しました。

image.png

  • 実行が完了したら、ジョブから解析結果の保存先パスが確認できます。

image.png
image.png

  • 解析結果は以下の形式で保存されています。
    SentimentScore には文書がその感情である確度を示すスコアが入ります。
{"File": "ファイル名", "Line": 対象の文書が保存されている行, "Sentiment": "文章の感情", "SentimentScore": {"Mixed": スコア,"Negative": スコア, "Neutral": スコア, "Positive":スコア }}

解析結果

口コミサイトの口コミ感情分析を行った結果は以下のようになりました。

まず一番、多いのが NETUAL でした。
次に多いのが、NEGATIVE でした。
この結果から、弊社の運営する口コミサイトでは基本中性的な口コミばかりだが、ネガティブな口コミも比較的多くみられることがわかりました。

項目 総数
POSITIVE 3780
NAGATIVE 10269
MIXED 1316
NEUTRAL 30627

料金

今回の検証にかかった料金を以下に示します。

  • 感情分析の利用料金
項目 金額
10Mユニットまで 1ユニット当たり0.0001USD
10M~50Mユニットまで 1ユニット当たり0.00005USD
50Mユニット以上 1ユニット当たり0.000025USD

※1ユニット = 100文字

  • 今回利用したユニット数
    6722465文字 / 100 = 約67224ユニット
  • 利用料金
    67224 * 0.0001USD = 6.7724 USD

おわりに

今回は、Amazon Comprehend を利用して口コミの感情分析を行ってみました。
約4万6千件ものデータをたった7分、しかも700円ほどで解析できてしまいかなり驚きました。

会社やイベント等のアンケートやレビューを安く、早く、簡単に分析したい。
そんな場合は、ぜひ Amazon Comprehend を利用してみてはいかがでしょうか。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Solutions Architect Professional合格記録

どしたん

先日、AWS Solutions Architect Professionalに合格したので
今回も取り組んだことを残します。

因みに、以前情報収集したメモは残しているので
そちらと被る内容は省略します。

まず試験概要

AWS 認定ソリューションアーキテクト – プロフェッショナル

必要な知識など
AWS2年以上相当の実務経験
主にAWSクラウドのアーキテクチャ設計/提案やデプロイに関する分野
エンタープライズ規模のスケーラブルな運用設計、デプロイ
AWS Well-Architected フレームワークの適用
Linuxなどのある程度の知識
など

前回からやったこと

※前回はこちら
AWS ソリューションアーキテクトプロフェッショナル受けた記録 - Qiita

改めて以前の敗因を記載すると主に
・少々特殊な日本語の読解力不足
・知識が明らかに足りないAWSサービスがあった
・コストを考えたアーキテクチャの設計ができなかった
・DBの知識が足りなすぎて時間をかけてしまった
です。

なので、以下に取り組みました。
①問題演習を繰り返して「試験問題」になれる
こちら
AWS WEB問題集で学習しよう | 赤本ではなく黒本の問題集から学習する方向け
 ★いくつかに分けて何周かします。
 私は集中力がそんなにもたなかったので、5~10(x7問)で一区切りしてもう一回。

②試験範囲や問題集の中で、ほとんど知らないor使った経験がないサービスの学習/検証
私の場合はこちら
・AWS EMR(各種)
・Kinesis系(重要)
・Rekognitionなど
・Application Discovery Service
・Storage Gateway(種類が大事)
・AWS Batch
 検証する場合は、AWS公式のチュートリアル、またはQwiklabsがおすすめです。(以前の記事参照)

③複雑なアーキテクチャを設計する際や、移行の問題にてよく比較するサービスの料金体系や連携方法を学習
 主な対象サービス
・S3
・DynamoDB
・DirectConnect,VPN
・Snowball,Snowmobile系
ちなみに試験概要見ればわかりますが、移行計画の問題だけでも15%出ます。
これは私の大きな弱点で前回致命的だったのでしっかり補完。
対象のAWSドキュメントを読むだけで十分なことも結構あります。

試験概要:下記AWSサイト内「試験ガイド」PDFファイルを参照。(2019/11/27)
https://aws.amazon.com/jp/certification/certified-solutions-architect-professional/

結果

時間余りませんでしたが、合格

前日に受けた模擬試験はなんと50%
多分、疲れ果てた状態で流し見して解いたから・・・?
もちろん総復習しました(正解がわからないから超大変だったが)

当日試験問題に解答していく毎に、自信5割/不安3割/カオス2割が増えていき、
最後の方は目が霞んでいましたが、結果を見て安心しました。

SAPを受ける方は、以前にSAAなどの試験を受けているかと思います。
できれば、慣れているテストセンターで受けられることをお勧めします。
私はずっと同じ会場で受けていますが、大正解でした。

あとは試験前に(飲む人は)コーヒー
相当な集中力を要します。
試験中にトイレくらいはOKなはずなので大丈夫。

まとめ

あくまで試験です。
AWS SAP試験用の対策を、努力して取り組めばちゃんと取れます。

今後は、実際にサービスを検証したり、実務で役立てたりしていこうと思います。
また、Dev系の資格やネットワーキングのSpecialistもタイミングを見て取得します。

今回改めて、会社で既に取得している方々の偉大さを感じました(笑)

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Solutions Architect Professional 合格記録

どしたん

先日、AWS Solutions Architect Professionalに合格したので
今回も取り組んだことを残します。

因みに、以前情報収集したメモは残しているので
そちらと被る内容は省略します。

まず試験概要

AWS 認定ソリューションアーキテクト – プロフェッショナル

必要な知識など
AWS2年以上相当の実務経験
主にAWSクラウドのアーキテクチャ設計/提案やデプロイに関する分野
エンタープライズ規模のスケーラブルな運用設計、デプロイ
AWS Well-Architected フレームワークの適用
Linuxなどのある程度の知識
など

前回からやったこと

※前回はこちら
AWS ソリューションアーキテクトプロフェッショナル受けた記録 - Qiita

改めて以前の敗因を記載すると主に
・少々特殊な日本語の読解力不足
・知識が明らかに足りないAWSサービスがあった
・コストを考えたアーキテクチャの設計ができなかった
・DBの知識が足りなすぎて時間をかけてしまった
です。

なので、以下に取り組みました。
①問題演習を繰り返して「試験問題」になれる
こちら
AWS WEB問題集で学習しよう | 赤本ではなく黒本の問題集から学習する方向け
 ★いくつかに分けて何周かします。
 私は集中力がそんなにもたなかったので、5~10(x7問)で一区切りしてもう一回。

②想定試験範囲や問題集の中で、ほとんど知らないor使った経験がないサービスの学習/検証

私の場合はこちら
  ・AWS EMR(各種)
  ・Kinesis系(重要)
  ・Rekognitionなど
  ・Application Discovery Service
  ・Storage Gateway(種類が大事)
  ・AWS Batch

 検証する場合は、AWS公式のチュートリアル、またはQwiklabsがおすすめです。(以前の記事参照)

③複雑なアーキテクチャを設計する際や、移行の問題にてよく比較するサービスの料金体系や連携方法を学習

取り組んだ主な対象サービス
 ・S3
 ・DynamoDB
 ・DirectConnect,VPN
 ・Snowball,Snowmobile系

ちなみに試験概要見ればわかりますが、移行計画の問題だけでも15%出ます。
これは私の大きな弱点で前回致命的だったのでしっかり補完。
対象のAWSドキュメントを読むだけで十分なことも結構あります。

試験概要:下記AWSサイト内「試験ガイド」PDFファイルを参照。(2019/11/27)
https://aws.amazon.com/jp/certification/certified-solutions-architect-professional/

結果

時間余りませんでしたが、合格

組織の複雑さに対応する設計:十分な知識を有する
新しいソリューションの設計:十分な知識を有する
移行の計画:十分な知識を有する
コスト管理:十分な知識を有する
既存のソリューションの継続的改善:再学習の必要あり

分野別でもこんな風に結果出ます。
前回まではSAでもコストがだめでしたが、初めて克服した・・・!

前日に受けた模擬試験はなんと50%
多分、疲れ果てた状態で流し見して解いたから・・・?
心が折れる手前もちろん総復習しました(正解がわからないから超大変だったが)

当日試験問題に解答していく毎に、自信5割/不安3割/カオス2割が増えていき、
最後の方は目が霞んでいましたが、結果を見て安心しました。

SAPを受ける方は、以前にSAAなどの試験を受けているかと思います。
できれば、慣れているテストセンターで受けられることをお勧めします。
私はずっと同じ会場で受けていますが、大正解でした。

あとは試験前に(飲む人は)コーヒー
相当な集中力を要します。
試験中にトイレくらいはOKなはずなので大丈夫。

まとめ

あくまで試験です。
AWS SAP試験用の対策を、努力して取り組めばちゃんと取れます。

今後は、実際にサービスを検証したり、実務で役立てたりしていこうと思います。
また、Dev系の資格やネットワーキングのSpecialistもタイミングを見て取得します。

今回改めて、会社で既に取得している方々の偉大さを感じました(笑)

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

使用しているプロダクトのセキュリティ情報をGASで収集してみた

なぜかアドベントカレンダー2019に向かって記事を書いている…

弊社はクラウド上でプロダクトを提供していて開発を内製化している。
だからこの弊社のアドベントカレンダー2019も硬軟取り混ぜてプログラミングに関する様々なネタが投稿されている…が私は現役でプログラミングをしていないしプログラミングに関与していない。
だが枠がある以上は書く(キッパリ)
では何を書くか?
このままでは与太話で終わってしまいそうになるが…
そうだ「セキュリティ」の観点なら少しは書けるかもしれない。

セキュリティって何?

あちらこちらで「セキュリティ」って使われるけど恐らく使う人も聞く人もそれぞれ自分の思う「セキュリティ」の範囲が違うと思う。
IT界隈に限ってもエンドポイントセキュリティを「セキュリティ」としている人もいればオフィスの入退室や「クリーンデスク」などの環境を含めたものを「セキュリティ」と言っている方もいるだろうと思う。
自社の「セキュリティ」の話をする前にそれぞれの認識を合わせておいた方が良いと思う。
ここではプロダクトの脆弱性情報を取り扱うことを主題にしています。

ところで(無理やり)Qiitaの記事の導入部

弊社のサービスはクラウドで提供しているのでGCPやAWSなどの利用に関するセキュリティの情報はそれぞれのプロバイダから得られるが( Amazon InspectorVulsって便利ですね!)、マネージドサービスを使用していない場合や個々人が使用しているプロダクト(みなさんエディタはお好きなものを使ってますよね?)などの情報は個別に集めるしかない。
メールマガジンを購読したり各プロダクトが提供する情報を個別に見るしかないのだが…面倒だ、実に面倒だ。

そこで(無理やり)Qiikaの記事の本題へ

実際にいくつかのプロダクトの情報を集めてみた
役に立ちそうなのはそれぞれのプロダクトのWebサイトやメールマガジンの他には
- IPA メールニュース配信
- JPCERT メーリングリスト
- JVN
などが広く情報を提供してくれるので便利だろう
もっとインフラの管理などをされている方など専門的に情報が知りたい場合には
- CWE
- CVSS
も参考にしてみてください(釈迦に説法)



が、メールでしか情報を提供していないプロダクトやメール配信をしていないプロダクトなど情報提供にはルールがないことを改めて確認したに過ぎなかった(やれやれ…)
なので割り切ってメールの情報とWebサイトの情報をGAS(Google Apps Script)で一元的に取り扱ってチャットへ投稿することにしてみた。

(ごく簡単な)方針

本当に簡単なルールだけ決めてスタートしてみた。
- 1日に一回、決まったタイミングで処理を実行する
- 投稿すべき記事があった場合だけチャットに投稿をする
- 投稿はタイトルと要約を転載し、詳細は記事中のURLから確認をする
たったこれだけw

メール配信記事の処理

兎にも角にも着信したメールを処理すれば良いだけなのであまり深くは考えない(確信!)
幸いにもメールシステムがGmailなのでGASとの連携は何の問題もありません。
面倒な手続きも最初にGASと連携するために「Gmailの承認」を得るだけ!
気にしたことは着信しているメールが処理済みか否かの判断だけ、これについてはGmailの恩恵をうけた。
プロダクトごとに受信メールにラベルを添付して、
チャットへの投稿が終わったら処理済みのラベルに貼り替える
、ただこれだけです。

GASでGmailのラベルを付与
GmailApp.getUserLabelByName(strPostlabel).addToThreads(myThreads);
GASでGmailのラベルを削除
GmailApp.getUserLabelByName(strPreLabel).removeFromThreads(myThreads);

Webサイト更新情報の処理

多くのWebサイトの情報は過去の情報も併せて記載されているので既にチャットへ投稿した記事を改めて投稿しないようにIndexが必要…これもGoogleスプレッドシートにIndexをすれば問題は解決です。
※多くは投稿日がIndexに使えますね

実際の投稿

メールもWebサイトもHTMLで情報が提供されることが多いのでタグで必要な情報を絞り込んで情報の単位ごとに分割、再構成します。

見た目のイメージは、例えばAWSの情報提供はこんな感じ そのSourceは↓です。
スクリーンショット 2019-11-27 15.47.02.png
こんな感じで投稿します
スクリーンショット 2019-11-28 13.35.46.png
まずはテーブルを、リストを処理して行単位に分割して…例えばこんな風に…

GAS
var aryBody = strContent.replace(/\n|\r|\t/gm,'').replace(/<link/gm,'<').match(/<li.*?li>/gm);

行単位に分割できれば要らないタグを削除して整形するだけです、こんな風に。

GAS
var strTitle = aryBodyTable[i].toString().replace(/<span>.*?<.span>|<.*?>|.para;/gm,'');

本文が長いものは折りたたんでいます。
IPAの情報だとこんな感じでチャットに投稿されます
スクリーンショット 2019-11-27 15.18.33.png
担当者がタイトルをみて自分の興味のあるものだけ目を通してくれればそれで良いと思います。

運用してみて

個人で使っているものを除いて考えても結局使われているプロダクトが多過ぎて一元管理が難しいこと…Wordpress1つとってもそのプラグインの情報まではなかなか追いきれない。
せめて一元管理が出来ていればと思うのだがその一方でサービス提供の迅速化や文書メンテナンスコストを考えるとやむなしかとも思う。
つまるところIPAの情報やJPCERTの情報も織り交ぜてチャットで広く情報を共有してそれぞれの担当者が気づいてくれるのが望ましいのかとも思った。
…担当者個人のリテラシーや力量にも依るけどね。

あと、GASの自動処理は”時間帯”が選べるのだけどあくまでも”時間帯”が選べるだけで自動実行する時間を指定できるわけではありません。
08時〜09時(AM)で指定してみたところ多少のブレは見られますがほぼ毎日08:45に処理が実行されています。
時間は指定できないけど一定のルールで処理が実行されるようです。
※日付ベースのタイマーを選択すると1時間枠が24示されますのでその中から選択します。
GAS ダッシュボード の各スクリプトの右端に隠れている”トリガー”で自動実行の条件を設定できます、念の為。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CodeDeployの結果をSlackに通知する

こちらはJoolen Advent Calendar 2019 6日目の記事です。
前日の記事は@kyoko2iさんのDoctrineでちょっと複雑なSQLを発行するでした。
カレンダーのURLはこちら
Joolen Advent Calendar 2019

まえがき

CodeDeployを使用しての自動デプロイは便利ですが、デプロイが終わったのかわからずコンソールを開いて確認するのが面倒ですよね。
なので、デプロイの結果をSlackに通知しようというのが目的です。
CodeDeployを使用したデプロイ方法には触れません。

大まかな流れは
CodeDeploy->SNS->Lambda->Slack
という感じで通知します。

SNSの設定

SNSのトピックを作成します。
名前と表示名を自由に設定してください。
その他は必須ではないので、自由に設定してください。
スクリーンショット 2019-11-27 14.07.57.png

Lambda関数の作成

SlackのWebhook設定

通知用チャンネルを作成した後下記のURLにアクセスしてwebhookを設定します。
https://slack.com/services/new/incoming-webhook

Post to Channelで作成した通知用チャンネルを選択してwebhookを設定し、Webhook URLを取得します。

スクリーンショット 2019-11-27 14.14.58.jpg

Lambdaの設定

今回Node.jsを使用して作成します。
関数名は自由に設定してください。
実行ロールは新しく作成するか、Lambdaへのアクセス権限を持ったロールを設定します。
スクリーンショット 2019-11-27 14.29.39.png

関数は以下の通りです
regionなどは適宜変更してください。

const https = require('https');
const url = require('url');
// 取得したWebhook URLを設定
const slack_url = 'https://hooks.slack.com/services/xxxx/xxxx';
const region = 'ap-northeast-1';
const codedeploy_url = 'https://' + region + '.console.aws.amazon.com/codedeploy/home?region=' + region + '#/deployments/';
const slack_req_opts = url.parse(slack_url);
const slack_color = {
  'SUCCEEDED': 'good',
  'ABORTED': 'warning',
  'FAILED': 'danger',
};
slack_req_opts.method = 'POST';
slack_req_opts.headers = {'Content-Type': 'application/json'};

exports.handler = function(event, context) {
  (event.Records || []).forEach(function (rec) {
    if (rec.Sns) {
      var req = https.request(slack_req_opts, function (res) {
        if (res.statusCode === 200) {
          context.succeed('posted to slack');
        } else {
          context.fail('status code: ' + res.statusCode);
        }
      });

      req.on('error', function(e) {
        console.log('problem with request: ' + e.message);
        context.fail(e.message);
      });
      var message = JSON.parse(rec.Sns.Message);
      var str = `deploymentGroupName: ${message.deploymentGroupName}`
      + `\ndeploymentId: ${message.deploymentId}`
      + `\nstatus: ${message.status}`
      + `\n${codedeploy_url}${message.deploymentId}`;

      req.write(JSON.stringify({
        username: 'CodeDeploy',
        attachments: [
          {
            color: slack_color[message.status],
            fields:[
              {
                title: "deployment result",
                value: str,
              }
            ]
          }
        ]
      }));

      req.end();
    }
  });
};

リクエストの中身に関しては公式ドキュメントを確認してください。
https://api.slack.com/docs/message-formatting
https://api.slack.com/docs/message-attachments

トリガーを追加

Lambdaからトリガーを追加します。

トリガーの設定画面でSNSを選択し、トピックは先ほど作成したトピックを選択します。
スクリーンショット 2019-11-27 14.45.00.png

CodeDeployの設定

通知したいデプロイグループの編集画面でトリガーセクションから「トリガーの作成」をクリックします。
なお、トリガーセクションは詳細として折りたたまれているので、お気をつけください。
スクリーンショット 2019-12-06 7.12.46.png

トリガー名を適当に設定し、イベントはデプロイの成功デプロイの失敗デプロイの停止を選択
その他にも通知したいイベントがあれば選択します。
トピックはLambdaのトリガーに設定したものと同じトピックを選択します。
スクリーンショット 2019-11-27 14.51.50.jpg

以上で設定は終了です。
実際にCodeDeployを動かしてみます。
スクリーンショット 2019-11-27 14.55.56.jpg
通知が来ました!

これで逐一確認する手間から逃れることができました。

明日は@y_shiraiさんです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSでJupyterHub (概要)

はじめに

こんちには,こんばんわ.
今年は,AWSやらPythonやらをいじっていた時間が長かったのか,「なにかしたいな~」と考えていた時,一人で黙々とやるのも好きなんですが,協同でなにかするのもそこそこ好きなので,ふと「そうだ,JupyterHubの環境を作ろう」と.
今回は,その時の内容を何回かに分けて記事にしようと思います.

でも,普通に「インストール後起動」だけじゃ物足りないので,次のような点を解決しながら環境を作ってみようと思いました.

  • 普通に「インストールして,起動して,アクセスする」的なものじゃ物足りない
  • アクセスするURLが http://localhost:8080/ のようなものも味気ない
  • ドメインが何かよく分からないものはイヤ(自分の好きなドメインにしたい!)
  • URLにポート番号付けるのとかカッコ悪い
  • 通信を暗号化させたい(HTTPS化)

ゴール

最終的に,以下の要素が達成できるようにしていきます.

  1. 好きなドメイン(サブドメイン)でJupyterHubにアクセスできること
  2. 通信の暗号化(HTTPS化)
  3. 複数アカウントを用意して,別々の環境が用意できること
  4. 各アカウントがJupyterHubで作成したデータやコードがJupyterLabが起動しているボリュームと別にあること
  5. WAFを利用した簡単なアクセスポイントの制御と監視

道のり

ゴールに向けて,AWSでやってみたことを順を追って書いていきます.
AWSをしっかりと勉強したわけでもないし,今回取った方法がベストプラクティスでもないと思うし,「こっちの方法が良いよ」とか「これじゃ面倒だよね」とかあると思います.
私の勉強不足のため,AWSを使いこなしてないです,IAM使ってセキュリティをしっかりとするとかね,今回やってません.

  1. EC2を使ってJupyterHubのサーバを用意
    1. EBSを使ってJupyterHub専用ストレージをマウント
  2. webサーバとしてnginxを用意
    1. リバースプロキシの設定
  3. pythonの準備
    1. anacondaのインストール
  4. Route53でドメインの獲得
    1. JupyterHub用のサブドメインの設定
  5. 通信の暗号化
    1. ALBとACMの設定
  6. JupyterHubのインストール
    1. JupyterHubのアカウントを作成
    2. ログの設定
    3. 毎日リブートさせる
  7. ELBにWAFを追加してアクセスを制御
    1. CloudWatch+SNSを使って監視メールの送信

各項目は,記事が出来次第,リンクに差し替えていきます.

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS MediaConvert 高速変換のTips

はじめに

最近、AWS Elemental MediaConvert(以下、MediaConvert)の
高速変換をいろいろ試したので、細かい情報をメモしておきます。

想定読者は、MediaConvertのサービス用途を理解していて、
かつ、MediaConvertを使って動画変換したことがある方になります。

つまり、細かい説明はしていませんので、ご了承ください。

用語

AWSドキュメントでは、「Accelerated Transcoding」や「高速トランスコード」と記載されていますが、
本記事の中では、「高速変換」で統一します。

ちなみに、標準トランスコードは「通常変換」と表現しています。

前提

実行に 10 分以上かかるジョブには、高速トランスコード の使用を検討してください。(※1)

MediaConvertで高速変換を実施する目安ですが、AWSドキュメントに上記の記載がありました。
通常変換で「10分以上」かかる場合は、高速変換を検討した方がいいようです。

設定

高速変換を行う際に、設定変更が必要な箇所を下記に載せておきます。

1. キューの作成

新規にキューを作成する(既に作成済みであれば不要です)。

2.「Start at 0」

「ジョブの作成」の後、次の2ヶ所を Start at 0 に設定する。

ジョブの設定

[ジョブの作成] - [設定] - [タイムコード設定] - [ソース]

➡︎ 「Start at 0」 に設定する。

ScreenShot 2019-11-28 17.44.45.png

入力

[ジョブの作成] - [入力] - [ビデオセレクタ] - [タイムコードソース]

➡︎ 「Start at 0」 に設定する。

ScreenShot 2019-11-28 17.33.07.png

3. 高速変換の有効化

ジョブの設定

[設定] - [高速化]

➡︎ 「Enabled (有効) 」 (または 「Preferred (推奨)」 ) を選択する。
※「Preferred (推奨)」については、この後の補足項目で少し説明しています。

ScreenShot 2019-11-28 17.51.39.png

料金

MediaConvertの使用料金は従量課金制となっており、最低料金はありません。
出力する動画の再生時間 (分) に応じて課金される料金体系になります。

また高速変換の場合は、下記を考慮する必要があります。

高速トランスコード はプロフェッショナル階層の機能です。プロフェッショナル階層の機能を使用する出力の場合、トランスコード出力の毎分の料金は高くなります。(*1)

  • ベーシック階層
  • プロフェッショナル階層

2つの階層があるうちの、高速変換はプロフェッショナル階層の料金として請求されます。
また、請求対象は出力尺のみのため、実行時間を気にする必要はありません。

※MediaConvertの詳細な料金体系の記述はここでは省略。末尾のリンクをご参照ください。(※3)

制限

入力・出力のコーデック等で高速変換がサポートされていない場合があります。
意外と盲点だったりするので、ご注意ください。

他にもサポート外の機能もあるので、高速変換を検討の際には要確認です。

高速トランスコードでサポートされないトランスコード機能 (※4)
・低速 PAL
・広告表示のブランキング
・モーションイメージ挿入 (モーショングラフィックオーバーレイ)
・補間型フレームレート変換
・VBI パススルー
・タイムコードパススルー
・SEI タイムコード
・タイムコードアンカー
・テレシネ出力
・逆テレシネ出力
・オープン GOP 出力
・埋め込みタイムコードソース
・デフォルトの 0 以外の Min-I 間隔の値
・ESAM
・SCTE-35 パススルー

補足

2019年10月9日、高速変換に "Preferred (推奨) " モードが追加されました。

これにより、高速トランスコーディングの品質に満たないジョブもエラーになるのではなく、標準トランスコーディングモードにフォールバックされます。トランスコーディングジョブは、何らかの操作をしなくても自動的に再実行されるため、作業の手間が省けます。(*5)

つまり、高速変換を有効にする場合は、下記のような考え方でよいと思います。

・高速変換してエラーになったら、変換をやめる:「Enable」
・高速変換してエラーになったら、通常変換を行う:「Preferred」

おわりに

MediaConvertの動画変換時間の短縮に繋がる高速変換ですが、
設定方法等分かりにくい部分もあるので、検討の際はまず実際に動かしてみることをオススメします。

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Technology Radar 2019のピックアップ

Technology Radarから気になったものをピックアップし、軽く説明を添えてみました。
社内で共有したところ、反響が良かったのでQiitaにも投稿します。

(自分と似た技術スタックの方に刺さるのではないかと考えています)

ピックアップの観点

「自社の技術スタックとマッチしてるか」「自分の技術スタックとマッチしているか」の観点からピックアップしています。

筆者は現在web系の企業のSREチームに所属しており、業務や趣味で触れる技術/言語としては下記のとおりです。

  • Ruby on Rails
  • Node.js / Vue.js / Nuxt.js
  • AWS + Terraform
  • Go/python/Firebase/GCP

一方で下記技術は興味が無い/専門じゃない等の理由でスルーしていますのでご注意ください。

  • モバイルアプリ系
  • ML系
  • JVM系

Technology Radarとは

要は今年のイケてる技術の紹介です。
4段階で導入のおすすめ度合いが評価されているので、毎年重宝しています。

TECHNOLOGY RADERとはThoughtWorks社が発表している技術トレンド分析の調査結果になります。 年1-2回発表しており、2016年は4月と11月に発表されました。

ユニークな点は、技術トレンドの分析を
Techniques(開発手法) / Tools(ツール) / Platforms (プラットフォーム) / Languages & Frameworks(言語とフレームワーク)
の4分野に分けているところです。
また、評価結果も ADOPT / TRIAL / ASSESS / HOLDの4つに分けているところです。

ADOPT : プロジェクトにマッチするならば、採用を強くおすすめしている。
TRIAL : プロジェクトでリスクを管理できればやる価値はある。
ASSESS: どのような影響をあたえるか理解するために採用するときがある。(今後のために採用するときがある)
HOLD : 採用する場合は慎重に進める必要がある。

引用元:https://allabout-tech.hatenablog.com/entry/2017/02/15/093000

気になった技術

それぞれの領域ごとに概要と所感を記載しています。

Techniques

Container security scanning (ADOPT)

もはやコンテナのセキュリティスキャンは必須の時代です。
CI/CDパイプライン内でスキャンを実施しましょう。

所感:ECRのscan on pushやtrivyで簡単に実現できそうなのでやっていきたい。

Pipelines for infrastructure as code (ADOPT)

ソフトウェアのCI/CDパイプラインによるデプロイが主流になってきました。
Chef/Puppet/Ansible、Packer、Terraform等の登場により、インフラレイヤーもCI/CDを実現することが可能です。
インフラレイヤーもCI/CD化することで、実行元の一元管理や、実行前のエラー検知ができるようになるので、是非やりましょう。

所感:Lint/validationやplan結果の表示もできるのでやりたい。stg/prdのapplyタイミングを踏まえて設計する必要があるのでちょっと大変かも。Dockerfileも現在はCIにかかってないので回すようにしたい。

security policy as code (TRIAL)

セキュリティポリシーをコード化し管理していきましょう。
Open Policy AgentIstio等であれば、ポリシー定義と実施メカニズムを提供しています。

所感:明文化してGit管理を開始したので、適用を強制したり検知する仕組みもあわせて実施していけるといい感じかも。

Tools

Commitizen (ADOPT)

http://commitizen.github.io/cz-cli/
対話形式でGitのコミットメッセージをサポートしてくれるツールです。
コミットの種類とか関連するIssueの有無とかbreaking changeの有無とか聞いてくれていい感じにメッセージを組み立ててくれます。
commitizen

所感:個人のリポジトリはコミットメッセージ英語なので、これを導入することで良さげなリポジトリに見えるようになりそう。

jib (TRIAL)

https://github.com/GoogleContainerTools/jib
Java用のコンテナイメージ作成ツールです。
MavenやGradleに対応しており、DockerfileやDockerデーモンを必要とせずにイメージをビルドします。

所感:使うことはまあ無いだろうけど、デーモン無しにイメージを作成できる技術は気になる。

Trivy (TRIAL)

https://github.com/aquasecurity/trivy
コンテナイメージのセキュリティスキャンツールです。

所感:今ではかなり有名なやつ。使っていきたい。

Twistlock (TRIAL)

https://www.twistlock.com/
Twistlockは、コンテナ環境向けセキュリティ製品です。開発環境から実行環境まで、包括的なセキュリティを提供します。
NIST/CISベンチマークなど、業界のベストプラクティスに沿った対策が可能です。
twistlock

所感:金額次第だが、セキュリティ要件厳しいサービスを運用する際にはいいかも。ただし、融通が利くかどうかは重要。

asdf-vm (ASSESS)

https://asdf-vm.com/#/
複数の言語のバージョンを管理できるコマンドラインツールです。
RVMやnvmのようにバージョンを管理できますが、複数の言語をこのツール1つで管理できるのが特徴です。

所感:ruby以外もバージョン固定して利用するプロジェクトでは良さそう。個人の環境は全部これに乗せ替えたい。

AWSume (ASSESS)

https://github.com/trek10inc/awsume
AssumeRoleをいい感じにやってくれるCLIツール
AWSume

所感:社内のエンジニアには基本的にassum roleして利用するIAMユーザーを配ってるので、これを標準の手順にしてみてもよさそう。(現在、MFAを利用していることもあり、AssumeRoleするユーザーでawscliを使う手順がやや面倒)

Pumba (ASSESS)

https://github.com/alexei-led/pumba
PumbaはDockerのためのchaos testingとネットワークエミュレーションのツールです。
ネットワークをエミュレートし、遅延、パケット損失、帯域幅レート制限などのさまざまなネットワーク障害をシミュレートすることもできます。

所感:chaos testingはやったこと無いので挑戦してみたい。

Platforms

Crux (ASSESS)

https://opencrux.com/
bitemporal graph queryを備えたドキュメントデータベースです。
bitemporalとは、履歴を持ったデータのこと

不変のトランザクションレコードも保持しながら、ビジネスの真の履歴を記録します。これがバイテンポラリティの本質です。開発者およびアプリケーションユーザーとして、時間をかけて効率的にクエリを実行する機能のロックを解除します。 Cruxを使用すると、遡及修正を作成し、履歴データの移行を簡素化し、異常なイベントデータの統合ビューを構築できます。

所感:特許で見たことあるような。履歴を持ち、かつそれを遡及して修正するシステムは本当に辛いので、これがマッチするなら使うのが良さそう。

Hydra (ASSESS)

https://www.ory.sh/hydra/
OAuth2、OpenID connect providerを簡単にホストすることができるOSSです。

所感:micro serviceをk8s上で構築する際に使えそう。認証系の自前メンテは辛いので、こういうものを活用していきたい。

Teleport (ASSESS)

https://gravitational.com/teleport/

『Gravitational Teleportは、SSHまたはKubernetes API経由でLinuxサーバーのクラスタへのアクセスを管理するためのゲートウェイです。従来のOpenSSHの代わりに使用することを目的としています。』

参考記事

所感:中規模以上のk8sを利用している場合に効果を発揮しそう。自前でteleportのクラスタを構築し、ライセンスも必要なプロダクトなので、導入するのはけっこうな大事。GitHubや任意のSSO連携可能なサービスのアカウントで、ロールに基づいたsshができるのはまさに我々が求めていたものである。

Languages & Frameforks

jest-when (TRIAL)

https://www.npmjs.com/package/jest-when
when(fn).calledWith(args).thenReturn(value)のような感じでモック関数の引数に対するレスポンスを定義できるプラグインです。

所感:地味に便利で記述量を少なくできるので良さそう。

NestJS (ASSESS)

https://nestjs.com/
TypeScript製のserver side Node.jsフレームワークです。
GraphQL、Websocket、ORMライブラリなどのプロトコルをサポートしています。

参考記事:Nest.jsは素晴らしい

所感:発想はRailsに近いように思える(レールに乗ることでスタイルが統一され楽に開発できる等)。expressとの2択になりそう。

Paged.js

https://www.pagedmedia.org/paged-js/
HTMLで書籍等の印刷物を作る場合に必要なページカウンターやヘッダー、フッター等を描画できるポリフィルとCSSモジュールを生成してくれるライブラリです。

所感:本を作る機会があれば使ってみたいかも。前職であれば仕様書は謎に文書形式である必要があったので、Markdownで書いた場合でもヘッダーやフッターを頑張ってつけてたから、それにも使えそう。

まとめ

個人的に気になった技術をいくつかピックアップして紹介してみました。

よくあるツール紹介でごめんなさい。
でも、元が英語だから許してね。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon CloudWatch Synthetics を試してみた

2019年11月25日に Amazon CloudWatch Synthetics のプレビューが公開されました。

Introducing Amazon CloudWatch Synthetics - Now in Preview

一言で言えば外形監視機能ですが、単に Web サービスの死活監視をするだけでなく、

  • ページ内の要素を監視する
  • レスポンスタイムを監視する
  • スクリーンショットを撮る
  • リンク切れを検出する

などなど、監視項目を柔軟に設定できるようです。

こういう機能欲しいな〜〜〜と思っていたところだったので、テンション爆上がりで早速試してみました。

監視項目を作成する

現時点では US East (N. Virginia), US East (Ohio), EU (Ireland) の3リージョンでしか使えないとのことですが、どのリージョンから監視をしても大して問題はないと思うので US East (N. Virginia) リージョンで使ってみることにします。

今回は会社のコーポレートサイトの死活監視をやろうと思います。

CloudWatch Synthetics では監視項目を Canary という単位で管理するようなので、まずは Canary を作成していきます。

image.png

blueprint から Heartbeat monitoring を選んでエンドポイントの URL を指定すると、その下の Canary Builder に監視内容を設定するコードが生成されます。

var synthetics = require('Synthetics');
const log = require('SyntheticsLogger');

const pageLoadBlueprint = async function () {

    // INSERT URL here
    const URL = "https://churadata.okinawa/";

    let page = await synthetics.getPage();
    const response = await page.goto(URL, {waitUntil: ['load', 'networkidle0'], timeout: 30000});
    await synthetics.takeScreenshot('loaded', 'loaded');
    let pageTitle = await page.title();
    log.info('Page title: ' + pageTitle);
    if (response.status() !== 200) {
        throw "Failed to load page!";
    }
    // 追記してみた
    if (pageTitle !== 'ちゅらデータ株式会社') {
        throw "Failed to load page!";
    }
};

exports.handler = async () => {
    return await pageLoadBlueprint();
};

まんま AWS Lambda の JavaScript コードですね。
ランタイムを Python に変えれないのかな

blueprint そのままの状態だと「ページにアクセスしてスクリーンショットを撮ってステータスコードが 200 以外だったら例外を投げる」という流れです。つまりは Lambda Function を記述して、何か異常があれば例外を投げればいいということです。わかりやすい。

synthetics は「クローラ + HTML パーサ」なモジュールのようなので、これを使えば「ページ内の特定の要素に期待したコンテンツが含まれているか」というような監視項目も簡単に記述できそうです。

image.png

監視コードを記述した後は、監視する頻度・監視データの保持期間・Lambda Function に割り当てる Role などの設定をします。Threshold については後述します。

監視データを見てみる

監視項目を作成した後にステータスを見てみると、Lambda Function の実行結果が見れます。

image.png

Canary を作成した時点で自動で S3 バケットが作成されて、監視ログやスクリーンショットなどはそこに保存されています。

スクリーンショットをよく見ると日本語が文字化けしていますね。(フィードバックを送った)

image.png

HAR File タブでは、各アセットのレスポンスタイムなどの詳細を見ることができます。

異常時のアラートを設定する

Canary Thretholds を有効にして各 Canary の設定でも Thresholds を有効にすると、CloudWatch Alarm が自動で作成されて異常時にアラートをあげることができるようになります。

image.png

作成された CloudWatch Alarm 側で閾値は変更できるようですが、デフォルト値は変更できないんですかね? (まだプレビューなので未実装なのかもしれない)

CloudWatch Alarm まで作成できればあとは Amazon SNS と連携してメールを送ったり Slack にポストしたりと自由自在に通知先を設定できます。このへんは特に新しい話でもないので割愛します。

料金

現時点では [Amazon CloudWatch の料金ページ](https://aws.amazon.com/jp/cloudwatch/pricing/) を見ても料金が書いてなかったのでわかりませんでした。

言語設定を英語にすれば料金が確認できました。

  • Lambda Function 実行にかかる費用
  • S3 バケットにデータを保存する費用
  • CloudWatch Alarm にかかる費用
  • CloudWatch Synthetics にかかる費用
    • 1回の Canary 実行あたり $0.0012
    • 1時間に1回実行する設定だと約100円/月

所感

新サービスと言いつつも背後に AWS Lambda + Amazon S3 + Amazon CloudWatch Alarms がいるサービスなので、そのへんを触ったことがある身としては学習コスト低めで使えてとてもわかりやすいです。それでいてとても柔軟な設定ができるのでかなり使えそうという印象。

CloudFormation や Terraform で Canary を自動で設定できるようになれば、詳細な監視項目を記述した上でそれをアプリケーションと同じリポジトリで管理できて便利なのでは?などと思いました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[awscli] lambdaのコード(zip)をダウンロードする

func=your-lambda-function-name
url=$(aws lambda get-function --function-name ${func} | jq -r '.Code.Location')
curl -o lambda.zip $url
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【クラウド初心者向け】Amazon Connectの案内音声を人間の音声に変更

概要

  • マイクを利用して音声録音を行います。
  • コンピューターの音声を録音した音声に置き換えます。

使用ユーザー

  • IAMユーザー

手順

  1. AWSにサインインします。

    1. アカウント、ユーザー名、パスワードを入力してサインインします。
      アカウント内(IAM)で作成したユーザーを使用してコンソールにサインインする
  2. 『AWSマネジメントコンソール』画面の右上にある《リージョン名》をクリックし、ドロップダウンます。
    image.png

  3. 『AWSマネジメントコンソール』画面にある「サービスを検索」にConnectと入力し、検索結果から《Amazon Connect》をクリックし、Amazon Connect コンソール(https://console.aws.amazon.com/connect/)を開きます。
    image.png

  4. Amazon Connectのインスタンス一覧が表示されるので、該当のインスタンスをクリックします。
    image.png

  5. インスタンスの概要が表示されるので《管理者としてログイン》をクリックします。
    image.png

  6. ダッシュボードの左側のメニューから《プロンプト》をクリックします。
    image.png

  7. 《プロンプトの新規作成》をクリックします。
    image.png

  8. 《レコード》をクリックします。
    image.png

  9. 《録音》をクリックし、音声案内に流す音声の録音を行います。
    image.png
    録音開始時と終了時の無音部分はツールを利用して削除する事ができます。

  10. 録音が終了したら《停止》をクリックします。
    image.png

  11. 録音した音声の波形が表示されるので、必要な部分をドラッグ&ドロップで選択し《クロップ》をクリックします。
    image.png

    1. 再生を押してクロップ後の音声を確認する事ができます。
  12. 「名前」入力して《作成》をクリックします。
    image.png

  13. 登録が完了し、音声プロンプト一覧に表示されます。
    image.png

  14. 左側のメニューから《問い合わせフロー》をクリックします。
    image.png

  15. 【クラウド初心者向け】Amazon Connectの問い合わせフロー作成で作成した問い合わせフローをクリックします。
    image.png

  16. 《プロンプトの再生》のタイトル部分をクリックします。
    image.png

  17. 右側に「プロンプトの再生」画面が表示されるので以下の設定をし、《Save》をクリックします。
    image.png

    1. プロンプトライブラリ(音声)より選択します。:選択します。
    2. プロンプトの選択:選択します。
    3. オーディオプロンプト:先ほど作成したプロンプトを指定します。
  18. 右上の《公開》をクリックします。
    image.png

  19. 《公開》をクリックします。
    image.png

目次に戻る

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon Web Services (AWS)サービスの正式名称・略称・読み方まとめ #17 (サテライト)

Amazon Web Services (AWS)のサービスで正式名称や略称はともかく、読み方がわからずに困ることがよくあるのでまとめてみました。

Amazon Web Services (AWS) - Cloud Computing Services
https://aws.amazon.com/

まとめルールについては下記を参考ください。

Amazon Web Services (AWS)サービスの正式名称・略称・読み方まとめ #1 (コンピューティング) - Qiita
https://qiita.com/kai_kou/items/a6795dbab7e707b0d1a6

間違いや、こんな呼び方あるよーなどありましたらコメントお願いします!

Satellite - サテライト

AWS Ground Station

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS LambdaのDestinationsを試してみる

AWSから割とすごい機能が発表されました。

Introducing AWS Lambda Destinations
https://aws.amazon.com/jp/blogs/compute/introducing-aws-lambda-destinations/

スクリーンショット 2019-11-27 6.51.44.png

Lambdaの実行結果に従って次のアクション(AWSサービス)を指定できる、というものです。
成功/失敗の条件で流れを制御したい場合には、Step Functionsを使う必要もなく、Lambdaだけで完結することができるようになりました。

早速試してみます。

呼び出し元のLambdaを適当に定義

こんな感じのPythonを書きます。(Python 3.7を利用)

import json
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)


def destination_sample_handler(event, context):
    logger.info("destination sample lambda started.")
    if event['Success'] == True:
        return {
            'statusCode': 200,
            'body': event
        }
    else:
        raise Exception('Success is False', event)

呼び出す際、event内にSuccess変数を定義し、その中身がTrueかFalseで判断を変えています。

Destinationを設定する

AWSブログではSNSとLambdaで成功/失敗の呼び出し先を変えてますが、手を抜いて両方Lambdaにしちゃいます。

こちらは成功パターン
スクリーンショット 2019-11-27 7.16.10.png

成功パターンの中身はこんな感じ。ただLogに出力しているだけです。

import json
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    logger.info("Success dest lambda started.")
    logger.info(event)
    return {
        'statusCode': 200,
        'message': 'Success in dest lambda',
        'body': event
    }

こちらは失敗のDestination設定
スクリーンショット 2019-11-27 7.18.20.png

中身は成功パターンと同じです

import json
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    logger.info("Failure dest lambda started.")
    logger.info(event)
    return {
        'statusCode': 200,
        'message': "Failure in dest lambda",
        'body': event
    }

実行してみる

実行はCLIから実施します。

$ aws lambda invoke --function-name destination-sample --invocation-type Event --payload '{ "Success": false }' response.json
{
    "StatusCode": 202
}

実行が成功すると202がStatusCodeとして返ってくるようです。

成功

成功させて見ると成功側のCloudWatch Logsにこんな感じの出力がありました。
CloudWatch Logs

[INFO]  2019-11-26T22:26:49.792Z    xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx    {'version': '1.0', 'timestamp': '2019-11-26T22:26:49.425Z', 'requestContext': {'requestId': '26fab6f9-a2b7-45f2-bce2-47c612cdb8b7', 'functionArn': 'arn:aws:lambda:us-east-1:000000000000:function:destination-sample:$LATEST', 'condition': 'Success', 'approximateInvokeCount': 1}, 'requestPayload': {'Success': True}, 'responseContext': {'statusCode': 200, 'executedVersion': '$LATEST'}, 'responsePayload': {'statusCode': 200, 'body': {'Success': True}}}

呼び出し先のeventの中身をログ出力しましたが、以下のようになっているようです。

  • conditionに成功/失敗が入る
  • requestPayloadに大元の呼び出し元eventが入る
  • responsePayloadに呼び出し元からreturnされた値が入る

少しコードを編集してeventにMessage要素を入れたところ、responsePayloadの中身が追加されました。

    if event['Success'] == True:
        event['Message'] = "Successful finished."
        return {
            'statusCode': 200,
            'body': event
        }
[INFO]  2019-11-26T23:41:21.229Z    xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx    {'version': '1.0', 'timestamp': '2019-11-26T23:41:20.730Z', 'requestContext': {'requestId': 'ba73f7a2-77f4-4166-a95d-d43020e5cc32', 'functionArn': 'arn:aws:lambda:us-east-1:000000000000:function:destination-sample:$LATEST', 'condition': 'Success', 'approximateInvokeCount': 1}, 'requestPayload': {'Success': True}, 'responseContext': {'statusCode': 200, 'executedVersion': '$LATEST'}, 'responsePayload': {'statusCode': 200, 'body': {'Success': True, 'Message': 'Successful finished.'}}}

ちなみに成功時のDestinationを一つ増やしたところ、On success側の設定が上書きされました。一つの条件に対して呼び出せるサービスは一つのようです。

スクリーンショット 2019-11-27 8.55.42.png

Add destinationを実施してもOn successの呼び出し先が上書きされるだけ。

スクリーンショット 2019-11-27 8.40.59_deco.png

失敗

失敗側も似たようなログがCloudWatch Logsに出ました。

[INFO]  2019-11-26T22:30:46.594Z    xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx    {'version': '1.0', 'timestamp': '2019-11-26T22:30:46.203Z', 'requestContext': {'requestId': '6fc2d258-fafb-40a2-8d18-886df8510fa1', 'functionArn': 'arn:aws:lambda:us-east-1:000000000000:function:destination-sample:$LATEST', 'condition': 'RetriesExhausted', 'approximateInvokeCount': 3}, 'requestPayload': {'Success': False}, 'responseContext': {'statusCode': 200, 'executedVersion': '$LATEST', 'functionError': 'Unhandled'}, 'responsePayload': {'errorMessage': "('Success is False', {'Success': False})", 'errorType': 'Exception', 'stackTrace': ['  File "/var/task/lambda_function.py", line 17, in destination_sample_handler\n    raise Exception(\'Success is False\', event)\n']}}

Exceptionの中身もきちんと伝搬してますね。

ちなみにX-Rayでの表示は?

X-RayではきちんとLambdaから処理が分岐しました。想像した通りとはいえ、これはすごい。ほぼこれでトレースもできますね。

スクリーンショット 2019-11-27 8.51.34.png

まとめ

簡単に成功/失敗での処理の分岐が実現できてしまいました。ちょっとしたスクリプトの制御であればこれで十分ですね。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

やねうら王を AWS Lambda で動かす

やねうら王 は 2019 年現在最も強い将棋 AI の一つです。AWS Lambda 上で実行できれば、API Gateway と連携したりして夢が広がります。
やねうら王 V4.88 を AWS Lambda 向けにビルドしてみよう。

実行環境

AWS Lambda の実行環境 OS は Amazon Linux 2 なので、Amazon Linux 2 上でビルドすれば十分です。
SIMD 拡張命令は 2017 年時点で SSE 4.2 が動くらしい。

ビルド

Amazon Linux の Docker イメージ を使うと楽です。
ビルドに必要なパッケージは下記の通り。

FROM amazonlinux:2.0.20191016.0

RUN yum install -y gcc gcc-c++ make build-essential git

MakefileTARGET_CPU = SSE42, COMPILER = g++ の 2 箇所を変更した後、

$ make normal

コマンドですんなりビルドが通ります。
DockerfileMakefile の全体像は下記の通り。

https://github.com/na-o-ys/shogi-api/tree/549418f0e8f3ee1dd686bf537dda9198b51cba3a/builder/YO488

実行

評価関数とあわせて何らかの方法で Lambda にバイナリ配置して、お好きなように呼べば良いです。
Serverless Framework を利用して API Gateway から呼び出す場合のサンプルコードはこちら。

https://github.com/na-o-ys/shogi-api/blob/549418f0e8f3ee1dd686bf537dda9198b51cba3a/serverless/src/handler.ts

(おまけ) dolphin 1.0.1

めきっと氏 (https://twitter.com/_illqha) の dolphin1 もほとんど同じ流れで AWS Lambda 向けにビルドできます。

https://github.com/na-o-ys/shogi-api/tree/549418f0e8f3ee1dd686bf537dda9198b51cba3a/builder/dolphin101

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む