技術一課でOJT中の鎌田です。休日にたまたま通りがかったのですが、丸の内でライオンズクラブの薬物乱用防止パレードが催されており、河北麻友子さんをお見かけしました。眼福です！
さて、先日Atlassian様のオフィスにて行われた、JAWS-UG横浜-Reboot!!に参加しましたのでレポートをします。会場では、ASCII.jp様のご好意でピザの提供が行われました。
http://jawsug-yokohama.connpass.com/event/40497/
発表内容
・WordPress using AMIMOTOのNext Step!! 堀内康弘さん
・価値のパイプライン with AWS CodeDeploy 長沢智治さん(Atlassian)
・AWS IoTを使う上でのNext Step!! 中田聡さん(オルトプラス)
・RDS MySQLからAuroraへ移行した話 @fujiwaraさん (KAYAC)
発表内容(LT)
・ドSIでクラウドっぽくAWSを運用するためのNext Step!! 瀬戸島敏宏さん
・[提案] Stream Batch Pattern (CDPのNext Step!!) 鈴木亮さん(クラスメソッド)
・サーバーレスアーキテクチャ (インフラ抽象化のNext Step!!) 大喜多利哉さん(さくらインターネット)
・この秋からCloudWatch Logsと仲良くなろう 多田貞剛(弊社エンジニア)
WordPress using AMIMOTOのNext Step!!
堀内康弘さんの発表です。堀内さんは、自身の旅の記録を綴ったブログをAMIMOTOを使って運営しているそうですが、AWSが発表しているWell-Archtected Frameworkというものを用いて、既存のAWS環境が優れた構成になっているか、一連の質問を通じて検証を行いました。
四つの柱
Well-Architected Frameworkは、以下の四つの柱で成り立っています。
・セキュリティ
・信頼性
・パフォーマンスと効率
・コストの最適化
セキュリティ
セキュリティ要件では、ACMの利用をし、SSL化を行うことが推奨されています。今回は、ACMで発行した証明書をCloudFrontに設定しました。
MFA認証の有効化も推奨されており、今回は仮想MFAデバイスを利用して有効化しました。
信頼性
ディスク溢れを防ぐために、Amazon CloudWatchにディスク使用率を表示できるようにするAmazon CloudWatch Monitoring Scripts for Linuxを使用します。
また、Lambdaで毎日スナップショットを取得しているそうです。Auto Recoveryの設定もしています。
パフォーマンスと効率
静的/動的ファイルをCloudFrontで配信しています。メディアファイルは基本的にAmazon S3に置き、オリジンアクセスアイデンティティを設定してS3から直接配信できないようにします。
CloudFrontを利用する理由として、SSL化を行うこと、またTCP最適化によりアクセス速度が改善するからとのことでした。
コスト最適化
リザーブドインスタンスを使用すると、3割ほどのコスト削減になります。
月$12ほどで、運用ができているとのことでした。
価値のパイプライン with AWS CodeDeploy
Atlassian、長沢智治さんの発表です。
Atlassianは、企画からバックログ、タスクボード、コーディング、ビルド、デプロイそれぞれに対応したツールを制作しています。
ツールは連携できるように設計されています。例えばConfluenceで課題を起票すると、自動的にJIRAのタスクボードにチケットが起票されるようになっており、エンジニアはチケットに対してタグを設定することができます。
JIRAでつけられたタグはConfluenceに反映されるようになっているので、エンジニアとマネージャの連携が取れるようになります。
エンジニアが書いたコードは、Bitbucketに保存し、bitbucket pipelineを使用することでデプロイを行うことができます。
AWS IoT利用の流れ
オルトプラスの中田聡さんの発表です。
利用の大まかな流れは、
・Thing登録
・キーペアの作成
・ルート証明書の取得
・ポリシーの生成
・ルート証明書とポリシー紐付け
・ruleの作成
です。
複数のポリシーやThingを登録する際にはCLIを使用し、定型の構成ができてきたらCloud Formationを使用すると良いとのことでした。
クラウドサービス三社のIoT機能比較
AWS,Microsoft Azureはビルディングブロックであり、IoT向けのサービスが展開されていますが、Google Cloud PlatformはIoT特化型のサービスは展開されておらず、複数のサービス(pub/subなど)を利用することで実現ができます。
主要なプロトコル
デバイスとのやりとりは、HTTP以外のプロトコルのサポートが重要です。
主なプロトコルとしては、MQTT、AMQPが挙げられます。MQTTはヘッダが軽量で、HTTPの1/10程度のトラフィックで済むため小型のデバイスとの通信に向いています。また、TLSを使用することで安全に通信を行うことができます。
AMQPはEnterpriseに対応出来るプロトコルで、信頼性が高く、アクセス制御ができます。
AWS IoT Device GatewayはMQTTおよびWebSockets経由の発信と受信をサポートしています。
Azure IoT HUBは、AMQP、MQTTをデフォルトでサポートしています。
Googleは独自プロトコル[weave]を開発しています。
weaveのgitレポジトリはこちら
git clone https://weave.googlesource.com/weave
課金体系
AWS、Azureはメッセージ数ベースで、GoogleはAPIコール数で課金されます。メッセージの単位は下記の通り。
AWS : 512Byte
Azure : 4KB
Google : 64KB
マルウェア感染のリスク
不正プログラム[Mirai]によるIoTデバイスを悪用したDDoS攻撃に世の中が騒然としましたが、デバイスのマルウェア感染を検知することができるのでしょうか？
現実的には、難しいとのことです。ただ、ユーザーが事前にできることはあります。
AWS IoTでできる対策
コンフィグをデバイスの環境ごとに変える場合は、デバイスごとにIoTルールを設定します。また、デバイスのジャーナルログをS3に送って、ログ解析を行います。
やってみて、動いた！という段階から、セキュリティを意識しよう、ということでした。
RDS MySQLからAuroraへ移行した話
面白法人カヤックの@fujiwaraさんの発表です。
発表スライドはこちら。
MySQLからAuroraに移行した理由①
MySQLでは、別AZにEBS書き込みを行うと時々、数秒から数十秒遅くなる現象がありますが、Auroraだと3AZ中2AZへの書き込みが終わった時点で返ってくるのでレイテンシが小さいそうです。
MySQLからAuroraに移行した理由②
リードレプリカはEBS Snapshotから復元されますが、その際にファーストタッチペナルティが適応されないように、primary keyとsecondary indexを全て舐める処理を走らせる必要があり、イベント前のサイズ変更がしにくい問題がありました。
移行結果
移行によって、EBSのファーストタッチペナルティーが無くなりました。クエリのレイテンシが取得できるようになり、リードレプリカの暖気が必要なくなりました。EBS snapshotはMySQLの際には性能に影響していたのですが、Auroraでは影響がないとのことです。
特に、I/Oの安定性が良くなったそうです。
ドSIでクラウドっぽくAWSを運用するためのNext Step!!
瀬戸島敏宏さんの発表です。
事例１
サーバーレスアーキテクチャを盛り込んだ設計を提出したところ、よくわからないのでインスタンスを立ててくれと言われ、設計し直しすることに。
事例２
MFAを採用したものの、運用に際してはトークンデバイスを金庫に保管する必要があることも。
要件を満たしつつ自動化を
構成図、エクセルシートが欲しいという要件はあります。その要件を満たしつつ、なるべく自動化をするべく、エクセルシートを自動生成するスクリプト、構成図を生成できるGUIのウェブアプリケーションを自作したそうです。
[提案] Stream Batch Pattern (CDPのNext Step!!)
クラスメソッドの鈴木亮さんの発表です。
Queuing Chain Pattern
Cloud Design Patternの一つ、Queuing Chainパターンは、システムを疎結合にできる点で、障害対応や部分的なスケールアウトがしやすいというメリットがあります。
しかし、スケールアウトのタイムラグや、EC2のコストがかさむ点が課題でした。
Stream Batch Pattern
そこで、Amazon KinesisやLambda,S3を組み合わせた、Stream Batch Patternを適用することによって、冪等性を担保し、コスト効率の良い構成が可能になるとのことでした。
サーバーレスアーキテクチャ (インフラ抽象化のNext Step!!)
さくらインターネットの大喜多利哉さんの発表です。
クラウドを使わない立場から見た、AWSのすごいところ
OSやアプリの管理がLambdaを使うことによってする必要がなくなりました。
ワークロードがサーバーレスになるにつれて自然と疎結合なマイクロサービスになるのでは、とのことでした。
サーバーレスの効能と動向
今の所、工数は変わらないが、運用が楽になっているとのこと。一方、AWSはEC2の機能を強化していることから、すべてのワークロードがサーバーレスになるとは思っていないことがわかるとのことでした。
この秋からCloudWatch Logsと仲良くなろう
弊社エンジニア多田の発表です。
解決したい課題
CloudWatch Logsに設定したアラームの通知内容は、アラームが通知されたことはわかるが、どんな操作を行ったかや通信元のIPアドレス等の詳細な情報がお客様にとって見にくい、という課題がありました。
解決策
そこで、Cloud Watch Logsのサブスクリプション機能を利用し、Lambdaで整形を行うPythonスクリプトを作成しました。これにより、必要な情報のみが抽出、整形されたアウトプットを取得できるようになりました。
今回の発表はCloudWatch Logsがメインでしたが、前半にCloudWatchのアップデートも合わせてレポートされていました。
CloudWatchのメトリックスの保存期間は15ヶ月まで伸びましたが、監視データの粒度によって保存期間に違いがあるので注意が必要とのことです。
公式資料はこちら。
LT発表資料は以下をご参照ください。
終わりに
テーマが決まっていない勉強会は、ラテラルに知識を身につけるにはもってこいですね。勉強になりました。
