AWS Community Day Kanazawa に参加してきました

awscommunityday2019.jaws-ug.jp

日本で初開催のAWS Community Dayが隣の石川県であるということで、平日ですが参加してきました。

AWSについては、2, 3年前は仕事でちらほら触っていたのですが、最近ではAndroidアプリなどのクライアント側が多く、ここ1ヶ月ぐらいでまた触り始めた、という感じでした。
そのため、最近の事情に疎く、そのあたりのキャッチアップをしたかった、というのも参加の動機でした。

直近で富山Ruby会議の運営に関わっていたこともあり、スポンサーがいっぱいだったり、2トラック＋ハンズオンだったりで、大変だったろうなーと思いました。
進行はスムーズで、様々な種類のトークがあり、すごく良かったです。

平日の、AWS自体が共催？ということで、もっとスーツ系の人が多いのかと思ってましたが、実際にはそんな雰囲気ではなく、実際に手を動かして使っている人が多い印象を受けました。

以下、参加したセッションと、その感想など。

基調講演 ～インフラからテクノロジープラットフォームへ～

AWS亀田さんのセッション。

基調講演らしく、「なぜAWSを使うのか？」や「そもそもクラウドを利用することでどんな利点があるのか？」といった幅広い話だったと思います。

個人的には、「AWS内の"非"マネージドサービスはEC2しかない（と言っても過言ではない、ぐらい？）」というのが意外と衝撃的でした。
たしかに思い返してみるとそうなのですが、意外と実感してなかったです。

あとは、「社内にテクノロジーのblackboxを作らない」のが良いなと思いました。
受託の開発をしていると、納品後の動向がわからないこともあり、このあたりまで追ってあげる方がお客さんのためなのでは？と感じました。

今覚えておきたいWell Architected Framework(W-A)と便利なツール

AwS舘岡さんのセッション。

Well Architected Frameworkについて、なんとなく存在は知っていたけど、今回で初めてちゃんと中身を知った気がします。
直近で、インフラの構成やそのレビュー？をする機会があるので、こういったツールも使いながらやっていこうかと思いました。

また、ほとんど知らなかったSystems Managerがかなり便利そうでした。
SSM Inventoryでのデータ収集や、Sessions ManagerでのSSHなど、すぐに使えそうな知識を得られたのが良かったです。

AWSでAlexaスキル開発をスケール＆ブーストする

Alexaスキルをがっつり作る話。

「Alexaスキルを作る」ことは「Lambdaの関数を作る」とほぼ同義とのこと。
（音声の解釈などは勝手にやってくれるし、そこから音声化するのも勝手にやってくれる）

ASK CLIというものがあって、手軽に始めるには良さそう。
とはいえ、がっつりAWSのサービス群と組み合わせようとすると、いろいろつらみがありそう。

Cognitoと組み合わせたり、Amplifyと組み合わせたりで、Webとの接続も比較的簡単にできそう。

海外リモートワークとAWS運用

年に2ヶ月程度、台湾でリモートワークをしている話。

昔ながら？のオンプレ環境だと、物理サーバの世話など、リモートワークでは出来ない作業も多かったけど、AWSだとそもそも手元にないので、どこにいてもそんなに変わらないとのこと。

リモートをする上で気をつけていることとして、連絡が取れるように（取れない場合は事前に伝えておく）したり、サポートし合う関係を作ったりなど、自分も納得できる内容だったので、改めて気をつけていこうと思いました。

AWS・Lambdaを活用した薬局向けシステムのプラットフォーム構築

アパレル業界出身で、父の事業の一部を受け継いで？薬局関連のサービスを開発している話。

異業種から入ってきて、これだけ出来ているのはすげぇなーと思いました。
また、こういった企業が北陸にもあるんだなーという再認識が出来、よかったです。

AWS運用の事例紹介

受託のアプリ開発を、AWSのインフラを利用して行っている話。

開発期間が2〜6ヶ月が多いというのは、結構驚きつつ、よく考えれば自分たちも半年ぐらいでリリースする案件はちらほらある気もしました。
とはいえ、ユーザ数が結構多いアプリが多かったので、自分たちももっと効率よく作れるのでは？と考えさせられたセッションでした。

多拠点ガソリンスタンド在庫・販売大量データの漏洩分析・リアルタイム監視を支えるAmazon RedshiftとAWSインフラ構築

SNS禁止セッション。

「玉田工業株式会社」という社名は聞いたことがなかったのですが、ガソリンスタンドなどの地下タンクにおいて大きなシェアを持っている会社とのこと。

そこから、ガソスタの監視システムなどを、AWSを利用して構築しているとのこと。

製造業で実はすごいシェアを持ってて、そこから派生してシステムを作れば強いのに、そこに気づいていない企業は結構ありそう？と思いました。

拡張して使う Serverless & Amplify

アプリのリニューアルをするのに、ServerlessとAmplifyを使った苦労話。

TypeScriptをLambdaとReact Nativeで利用することで、同一言語でサーバサイドもクライアントも作ったとのこと。
たしかに、言語が同じであれば考え方もある程度共通化でき、少人数や短期間ではかなりメリットありそう。

Serverless Frameworkは、pluginがかなり充実しているようで、困ったら作る前に探してみたら良さそう？と思いました。

Amplifyのカスタマイズ方法も興味深く、機会があったらやってみたいと思いました。

クラウド活用で 社員数10倍増を乗り切った 6年間のIT施策を振り返る

いわゆる"情シス"を、ちゃんとやっていった記録の話。

情シスは、縁の下の力持ち的なイメージで、目立たないイメージがありましたが、こうやってきれいにまとめてもらうとかなり重要なポジションだと感じました。

また、昨今はいろんなサービスがあり、試用期間が設けられているものが多く、とりあえず小規模に導入してみてダメだったら乗り換える、というのが良さそう。

感想まとめ

Systems ManagerやAmplify、LambdaといったAWSのサービスを知る・理解することが出来たのはもちろん良かったのですが、
自分が住んでいる北陸で、独自のサービスや付加価値を提供している事例を知れたのがよかったです。

自分は、北陸に住んでいるとはいえ、東京の会社に所属して仕事をしているので、こういったコミュニティ経由でしか北陸の事情を知ることが出来ないので、 こういったイベントを企画してくれた運営の方々には感謝の気持ちでいっぱいです。

タイミング・知識が合致したら、今度は自分も登壇できるように頑張ろうと思います。

以下、当日にとってたメモ。

## オープニング

JAWS-UGについて
JaWS-UG 金沢について 2011年1月に活動開始。
AWS Community Dayについて AWsと共催。Community Dayとしては、日本で初めて。

トラックAが基本的なものがメイン。トラックBが応用的なものメイン。
写真撮影NGの人のために、ストラップの色が違う。

#jawsug #awscommunityday
が本日のハッシュタグ。

## 基調講演 ～インフラからテクノロジープラットフォームへ～

AWSのモデル。固定資産型からサービス型へ。
コスト削減だけでなく、ノウハウをためていくことを推進。
Digitalization（ソフトウェアによる価値最大化）を、開発者とともに目指していきたい。
モノは、買ったときが最大の価値を持っている。サービスは、日々進化していく。
アプリケーションを請負で塩漬けしても、AWS部分が進化していく。もったいない。
よく出るキーワード「サーバレスコンピューティング」
ただ、インフラ費用の見積もりが課題。プログラム実行回数とメモリで課金。
CAPEX / OPEX クラウドを利用することで、無駄のない投資。
CAPEXのほうが、価格が変動しないので良いと考える人もいる。
AWSはマネージドサービスを推進している。非マネージドサービスはEC2だけと言ってもいいぐらい。
ただ、マネージド・サービスはロックインに感じる人もいる。
アメリカの大きな企業の平均存続年数は67年->15年と、かなり短くなっている。サイクルの速さが大切になってくる。
障害を踏まえた設計指針：RTOとRPO このあたりの設計を、事前に行っておけば、決まってくるものが多い。
良いものを作ろうと思うと、コストが上がってくる。
AWSには、最新テクノロジーを利用するためのサービスが多くある。
ownershipを置いてきぼりにするのは問題が大きい。（データを外部のSIerに丸投げして機械学習させるなど）
「社内にテクノロジーのblackboxを作らない」という考え方が大事
re:inventでラスベガス行くなら、観光などと合わせ、UBERなどのサービスを経験してみるのがおすすめ。
Uberlization: 異業種がITを駆使して既存ビジネスを変えていく。
AWSでは、「強化学習」に力を入れている。
教師あり学習では、人間の能力でキャップされやすい。
強化学習：コンピュータ同士で囲碁の対戦をさせるなど。良い行動に対して報酬を与える。
DeepRacer：ラジコンカー。そこに搭載する学習モデルのシミュレーションなどを提供している。
ハンズオン「はじめての迷路学習」を提供している。
新しいことは失敗する。ただし、その経験を蓄積することで、良くなっていく。
10年間に何が変わるか？よりも、何が変わらないか？を考えたほうが良いことが多い。その実現方法を進化させていく。

## 今覚えておきたいWell Architected Framework(W-A)と便利なツール

パートナーソリューションアーキテクト
賢く・安全に使うために。ベストプラクティス集としてWell-Architected Frameworkがある。
クラウドネイティブとリフト＆シフトの2つのアプローチがある。
2015年のre:Inventにて発表後、毎年アップデート。
10年以上のSAとお客さんのベストプラクティスを無料で使える。
記載されたホワイトペーパーと、支援するAWSのSAで構成される。
最近、日本語化や、（PDFから）Web化された。
Well-Architected Toolが日本語対応。（ただし、動画は英語）
あくまで「原則」
クラウドでの一般設計原則
質問・回答の形式で、ベストプラクティス。
ただし、全てに則っているのが必須ではなく、リスク・改善点を顕在化させることが目的。
要件検討や、設計・構築・運用の各場面で、AWS W-Aを活用できる。健康診断のように、定期的に確認するのがおすすめ。
Cyber Agentでは、カスタマイズしたものを利用している。AWS W-Aは、あくまでAWSの考え。
W-Aのレビューは、システムの関係者全員を呼ぶのがポイント。それぞれで、優先することが違っている場合がある。
レビューの進め方が重要。ホワイトペーパーでは、3ページも解説している。
・お菓子を用意する。
・監査ではない。
・複数回実施する必要がある。設計前と本番前など。
短くて3時間ぐらい。長いと8時間とか。
r5.xlargeのほうが、r3.xlargeより性能高く安かったりする。見直しが大事。
マネージドサービスの9割ぐらいは、お客さんの声から生まれている。
GuardDutyなど、セキュリティ対策サービスなども登場してきている。
Systems Manager：サーバ群を管理するツールセット

Demo
EC2 -> SSM Inventoryに集約し、S3 -> Athena -> Quick Sightで可視化
Amazon Linuxであれば、Systems Managerにつながっている。（他のOSなどは、Agentのインストールが必要）
インストールされているソフトウェア・バージョンなどが一覧で出てくる。
Systems ManagerからSSHできる。踏み台が不要かつ、SSHのポートも開けなくてよい。
古くからAWSアカウントを持っている場合に、権限が足りなくてQuick Sightが上手く作れなかったりする。

## AWSでAlexaスキル開発をスケール＆ブーストする

Alexaスキルを作るのは、ほぼLambdaの関数を作ること。
ASK CLIというものが提供されており、標準の環境がかんたんに作れる。
構成管理はしてくれない。Nodeのバージョンが変わったりは手動で対応する必要がある。
CloudFormationが使えるASK CLIも作成中。現時点では、がっつり作りたい場合は別管理したほうが良さそう。
CodeStarを使うと、プロジェクトの作成がかんたんに行える。
S3をデータベースにする選択肢もある。DynamoDbより、従量課金がゆるやか。
クエリしないデータは、DynamoDBよりS3のほうが管理が楽。
adapterを差し替えれば、DynamoDBからS3に変えられる。
コールドスタート問題。VUIだと、ローディング表示もできず、ユーザが不安になりやすい。
serverless-warmup-pluginなどでウォームアップや、Lambdaではなく常時稼働（EC2など）に置き換えるなど。
Pollyは機能限定で、無料で使える。（自分で組み込まなくても良い）
AlexaはOAuth2でアカウントリンクできる。Congito User PoolsはOAuth2に対応している。
Amplifyを経由して、mobileアプリなどとも連携できる。
Alexaスキルを作成すると、$100クレジットがもらえる。

## 海外リモートワークとAWS運用

5年くらい前から、台湾と日本を行き来している。
1年で2回、1ヶ月程度が台湾。
そもそも、AWSのリモートを扱う場合、すべて手元にないもの。
そのため、国内にいても、海外にいても大差ない。

顧客・案件ごとにAWSアカウントを分離。
構成管理はCloudFormation。YAMLで書いて、GitHubで管理。
CloudFormation / Roadworkerの2つで管理。

オペレーションとしては、SSMを利用。
作業用の環境として、WorkSpacesを利用している。Office事務用など。

基本的には、SystemsManager経由でSSH。

リモートで気をつけていること。
・"システム"を止めないこと。冗長構成だったり。
・電話連絡がつくように。つかない時間は、予め連絡。
・リモート機関にできない仕事を残さないように、スケジューリング
突発の場合
・社内でプロキシしてくれる人
・ビデオコールでのサポート
・サポートし会える環境・関係性を作っておく
・最悪、帰国する覚悟

海外での通信環境
・LTEのみ。30日無制限で4,000円ぐらい。
・スマホ3台体制。日本のSIM端末も持ち、SMSでの2段階認証など。
　着信を確認し、050 plusで折り返す。通話料の問題など。

## AWS・Lambdaを活用した薬局向けシステムのプラットフォーム構築

アパレル出身。
兄と会社を立ち上げた。医療関係者向けのサービスを提供している。

在庫管理システムを作り、Xamarinでのアプリ、API/SDKを作りプラットフォーム化、AIで需要予測などと広げていっている。
父のシステムのノウハウを継承している。

薬局のインフラを整えていきたい。-> 在庫管理システムをプラットフォーム化。
本当のところは、自分たちの開発工数・管理工数を下げたい。セットアップを簡単にしたい。というのが本音。

## AWS運用の事例紹介

受託のアプリケーション開発がメインの事業。
開発は、2〜6ヶ月程度が一般的。
EC2とRDSとS3のみを利用することが多い。
Management Console、CloudWatch Backupを、リリース後の運用で利用する。

## 多拠点ガソリンスタンド在庫・販売大量データの漏洩分析・リアルタイム監視を支えるAmazon RedshiftとAWSインフラ構築

SNS禁止セッション

## 拡張して使う Serverless & Amplify

20年ぐらいやってるサービスをリニューアルしたい。既存の開発会社に不満があり、スイッチ。
リニューアル内容が固まっていない。現行の基本機能は必須。iOS/Android両方。
-> 動くものを早く作る必要があった。
バックエンドに、一部オンプレ環境があった。
そのまま移行すると、インフラの管理などに大きな工数がかかってしまう。 -> サーバレス
スマホ側は、Obj-CとJavaだった。それぞれ作る期間・経験値が無かった。
Node.js / React Nativeの組で作ることに。TypeScriptが共通。
serverless frameworkを利用することに。ローカルで実行でき、YAML+コマンドでデプロイできる。
serverless-offlineというプラグインで、ローカル実行できる。
オンプレとの接続に固定IPが必要 -> serverless-vpc-plugin
CloudFormation templateが200で制限されている。1APIで複数のCloud Formationリソースが作られる。 -> serverless-plugin-split-stacks
構成を再構築したい。EIPが変わってしまう。 -> serverless-plugin-additional-stacks -> vpc-pluginが不要に
VPCに入れたLambdaは、コールドスタートに10秒程度。 -> serverless-plugin-warmup
開発環境だけ欲しいリソース。 -> serverless-plugin-ifelse
こんな感じで、現在ではいろいろなpluginが入っている。探せばだいたいある。最終手段は、CloudFormationテンプレートを書く。

AWS Amplifyの拡張性
CLI + Cloud Services + Framework + Developer Tools
今回は、CLIとバックエンドが中心。
amplify <category> addなどを実行すると、CloudFormation templateが作成される。pushすると、適用される。
categoryとして存在しないもの、カスタマイズが必要になるものも出てくる。
・既存カテゴリーのテンプレートを編集
・カスタムCloudFormationスタックの追加
・プラグイン（最もパワフル）
例：クライアントからS3へアップロード。CloudFrontの署名付きURLを発行して任意のユーザに共有。
スタックを追加することで対応した。
1. CloudFormationテンプレートを追加する
2. amplify/backend/backend-config.jsonを編集する
3. コマンドを実行し、CLIに認識させる
backend-config.jsonに書くことで、他のリソースのARNなどを引き継ぐことができる。
プラグインには4つのタイプがある。category / provider / frontend / util。category / utilあたりをよくつくる。
pluginを作るコマンドがある。
プラグイン実装に関する情報は、まだ少ない。amplify-cliのソースが一番参考になる。
amplify-helpers配下には、便利な定義がいろいろ入っている。
最初はカスタムスタック作って、2, 3度必要になったタイミングでプラグイン化するのが良さそう。

## クラウド活用で 社員数10倍増を乗り切った 6年間のIT施策を振り返る

2018年の内容をアップデートしたもの。
情シスとして使っているAWSの話。
6年で、40人から370人になった。

独自の請求システムを使っていた。
営業と営業事務のやりとりなどで、てんやわんや。
-> IT推進室を結成して、関係者を消臭。（社長直轄の"推進室"とすることで、立場を明確に）
Salesforce -> 請求データ作成 -> マネーフォワード請求
見積システム・請求システム・個別のスプレッドシートなど、それぞれのパートで作成していた。
AWSから請求を吸い上げるサービスがあり、それをSalesforceに投入、そこからマネーフォワードに連携。
3年前は600通だった請求書が、現在では3200通になっており、昔の仕組みだったらかなり無理があった。
Lambdaを使っているが、そこは月4000円ぐらいで動いている。

次に、ユーザー管理に手を付けた。
各種サービスを利用していたが、人によってはパスワード使いまわしや、ポリシーを強制できなかったり。
ID基盤をActive Directoryに集約。SSOやLDAP導入。1Password Teamsを全社導入。
Slackだけは、連絡がとれなくなってしまうので、別管理としている。
ID無効化を集中管理できる。
パスワード定期変更運用を廃止できた。<-ISMS認証とかで突っ込まれても、上記の対応のほうが強いと回答できる。

リモートワーク
AWS上に、Sophos UTM設置。MarketPlaceにある。
本社に、SOCKS4プロキシーを設置。これで、本社のIPから出ていける。（DirectConnectを利用）
AWSをハブに、全拠点と通信可能。

労務周り
給与明細を手渡し・郵送、経費精算はExcelを印刷・押印だった。
SmartHR・マネーフォワードを導入

1 - 3 - 5 目指す人数・規模よりも大きなものを対応できる状況を。
誓約より制約。やってはいけないことは、出来ないようにする。
システム導入にあたって、机上比較より、トライアル。自社運用。業務の方を合わせる。
帳票のデザインなど、細かな部分は自社で構築・運用。コアな部分（Salesforceの処理部分）は、専門家に任せる。