この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
こんにちは、CX事業本部の田中孝明です。
7/16(火) に 株式会社Fusic様の セミナールーム で開催された [AWS] Fukuoka.dev #1 - とりあえずクラウドネイティブ - についてのレポートです。
とりあえずサーバーレス
Amazon Web Services Japan K.K. 西谷圭介さん（@Keisuke69）
- サーバーレス の Specialist Solution Architect
- Blog: Sweet Escape
- Blog: うどんか蕎麦だと蕎麦派のブログ
- AWSのサービスを使うデベロッパーを対象にしている Meguro.dev というイベントをやっている
- Fukuoka.dev も同じく、福岡のデベロッパー向けのイベントをやりたい
- ロゴが未定なので有志に募りたい
- Fukuoka.dev も同じく、福岡のデベロッパー向けのイベントをやりたい
すべてサーバーレスでやろうではない
- 「お金で時間を買う」という考え方
- AWS Lambda を利用することが絶対的にコストが安いわけではない
- 場合によっては ECS が安くつく
- 目指すべきこと
- いかに早く価値のあるシステムを作る
- 「差別化に繋がらない重労働」を「自分でやらない」
コンピューティングの進化
- 物理マシン
- プランニングに「推測」が必要
- 長時間かけて見積もりや調達を行う
- フィードバックサイクルが長い
- 仮想マシン
- ハードウェアとの独立性
- 迅速なプロビジョニング
- よりスケール
- Elasticなリソース
- コンテナ
- プラットフォーム非依存
- 一貫したランタイム環境
- リソースの利用効率も高い
- 隔離とサンドサンドボックス
- 起動時の速度
- サーバーレス
- 対象のサービス
- AWS Lambda
- AWS Fargate
- 連続的なスケール
- 幅広いプラットフォームの選択肢
- 仮想サーバの幅広い選択肢
- 対象のサービス
おさらい：サーバーレスとは
- 自動でスケール
- 価値に対する支払い
- オペレーションの責任範囲について
- お客様の管理範囲はアプリケーションコード
- ECS と EKS を活用するケースがある
- 使い分けたいニーズがなければ、とりあえずサーバーレス（サーバーレスファースト）
- うまくいかなかったらコンテナ、EC2と検討していく
- 明確につかい分けたいニーズがある場合
- 特性に応じて幅広い選択肢から選択
- 悩んだらSolution Architectに相談してください
CacooにおけるコンテナとGoとgRPCなどの話
株式会社ヌーラボ 木村（@cohhei）さん
クラウドネイティブやってますか
- クラウドネイティブとは
- スケーラブルなアプリケーションを構築および実行するための技術の総称
- 代表的な技術：コンテナ、サービスメッシュ、マイクロサービス
- 回復性などのメリットがある
- コンテナ、CI/CD
Cacoo について
- スライドも Cacoo で作る
- CacooのバックエンドはほぼGoで作られえている
- Fukuoka、NewYoke、Amsterdamのメンバーで作成している
- 分業について
- エディッター部分
- 福岡チーム
- ダッシュボード部分
- 海外チーム
- エディッター部分
Kubernetes
- Kubernetesで実現している
- 複数のホストVMを抽象化
- ホストマシンはあくまでマシンリソースのプール
- ホストマシンのコモディティ化
- 特定のマシン固有の運用・管理は不要
- コンテナ・ホストのスケールが容易
- Serviceによるロードバランシング
- Podへの通信を抽象化
- 共通のYAMLフォーマットで設定可能
- Podをスケールしやすい
- Docker化していく
- 新しい機能を作るときにコンテナ化していく
- デザインのリニューアルに便乗して ECS のサービスを移行
- EC2 → ECS → Kubarnetes
- チームの依存関係が減った
- 部分的な変更がしやすくなった
GO
- Goはクラウドネイティブとの相性がいい
- muiti-stage builds
- buildしたやつをコピーできる
gRPC
- オープンソースのRPCフレームワーク
- 遠隔手続き呼び出し
- インターフェースをプロトコルバッファで自動生成
- 双方向のストリーミング
- インターフェースはサーバー側で実装してあげると、他のサーバーで使える
- ProtocolBufferスキーマを定義させることで、通信するレスポンスの型を定義できる
- 型がきっちりしているのがメリット
テストについて
- 単体テスト
- 同じサーバーインターフェースを満たすモックを実装
- トランザクションはどうしている
- サービスをまたいだトランザクションは諦める
- アプリケーションレイヤーでトランザクションを頑張るのはお勧めしない
- Cacoo における Protofiles と生成したコードの管理
- Protocol Buffersファイルとは単一のリポジトリで管理、ファイルが更新されると
- JenkinsでJavaとGoのコード生成
- 他のプロジェクトは dep ensure などで取得
- Protofiles と生成されたコードのブランチは一致
いい感じにスケール
- Cacooの開発組織は海外と福岡に分かれている
- Kubernetesクラスタを EC2 で運用している
- Goはいいぞ
- gRPC使ってるよ
mockmockの大量のログをいい感じに捌きたい
株式会社Fusic 毛利さん
- mockmock のプロダクトオーナー
- 好きなサービスKinesis
mockmock
- IoT開発者向け擬似データサービス
- IoTの開発でネックになりそうなところ
- IoTのデータを送ってほしい
- モノにだって都合がある
- エラーデータを出せない
- シミュレータを作る
- 作った人にしか動かせない
- 思い通りになるモノを仮想的に作る
ログ処理機構
- 設定ファイルバイナリをDL
- ログの処理機構
- 詳細なログを撮りたい
- ログのサイズは送信データサイズによって大きく変動
- 最大稼働数は実績で５万台
- 稼働数によって費用もスケールするように
第1世代方針
- mockサーバーには何もインストールしない
- 監視とかアップグレードとかが面倒
- ログ処理機構にネットワーク帯域を割きたく無い
- Towor が 1分 ごとに集計
- 送信ごとにログを書き出す
- 何もインストールしなくてもいい
- ログの処理機構に咲くネットワーク帯域が最低限
- ログの伝達にやたら時間がかかる
- ログの内容が必要最低限しか無いので、異常系まで考えるとログの集約処理が複雑になる
第2世代方針
- ネットワーク帯域をある程度割くようにした
- 足りなかったらお金の力に頼っていこう
- DynamoDB On-Demand を利用した
- キャパシティユニットをあらかじめ設定しておく必要がない
- mock -> DynamoDB -> Streams -> Lambda -> SNS -> SQS ...
- 詳細ログが見れるようになった
- その代わり、ログ処理機構に咲くネットワーク帯域が大きくなった...
- DynamoDB On-Demand はゴリゴリ使うと高い
第3世代方針
- DynamoDBのキャパシティを確保
- 起動時に必要なキャパシティを予測できれば実現する
- 送信データサイズによってログのサイズが大きく変動
- 送信データサイズを予測するのは困難
- 送信データの部分だけ別の機構を使って保存すれば良いのでは
- キャパシティは増やす方向には回数制限がないけど、減らす方向には回数制限がある
- Amazon Elastic File System を利用
- 複数のサーバーからマウントできる共有ストレージ
- 容量が自動でスケールする
- スループットが制御可能
第4世代方針（これから）
- mockサーバーに何かをインストールするのを許容しよう
- 今こそ Kinesis と向き合おう
- 早くも EFS から脱却したい
- Amazon CloudWatch Logs を活用する
第5世代方針（あわよくば）
- Amazon Timestream を検討したい
- Preview 申請しているが...
always.fanで初Dockerにチャレンジ、ECSの導入における紆余曲折
イジゲン株式会社 平野（@fm609hr）さん
- Dockerにチャレンジした
- Docker / ECS / k8s なんとなく知っている方を対象に話します
- イジゲン株式会社 は大分の会社
- サービス always を作成しています
- いろんなお店の定額サービスを提供・販売
- サービス always を作成しています
歴史的経緯
- 採用について
- Chefに詳しいエンジニアがいない
- 利用している人に出会えない
- トラブルシューティングに時間がかかる
- 成長スピード促進のための見直し
- Chefに詳しいエンジニアがいない
Docker環境への移行
- コードベースでのインフラ管理
- データ分析強化
- AWSでのDocker環境
- ECS
- EKS
- ECSを選択した
- 比較的敷居が低い
- Fargate も検討した
ECS
- コンテナオーケストレーションサービス
- クラスタ
- URLのマッピング
- Web/API
- Prd・Stg環境
- サービス
- 複数のサービス・パスにマッピングなどを想定
- https://xxx/sv1
- https://xxx/sv2
- タスク
- コンテナの実行
- 複数の組み合わせ可能
- スケーリング
- コンテナ＃１
- コンテナ＃２
- タスク定義
- Dockerイメージの指定
- CPU/MEMの指定
- 環境変数など
- アプリケーションと連携
- アップデート頻度高い
実際につまづいた点
- ロギング
- awslofs で CloudWatch Logs に保存
- Lambdaで好みの場所に
- EC2 の管理
- ECS用に Optimize された AMI を利用する
- 起動したEC2はスケールアップできない
- 新しいサイズのEC2を追加後、削除
- セキュリティアップデート
- 定期実行
- Scheduled Taskを利用
- Cloud Watch Events でタスクを定期的に実行
- コンテナへのアクセス
- コンテナにアクセスしたくなることがある
- EC2 への SSH環境はあった方がよさそう
- セキュリティ的にはSSM経由がお勧め
- Code Pipeline でビルド
- ローカル環境でイメージ作成
- CLI で ECR ログイン情報を取得しECR登録
- タスク定義のCPU設定
- vCPU x 1024 の値が設定値
- エラー対応
- 原因がタスク起動か、アプリケーションかを分別
- ECS のコンパネでタスク起動ログを確認
- 正常起動している場合はアプリケーションログを
- ヘルスチェックに失敗すると、タスクが再起動
- WEBサーバー起動失敗 or ヘルスチェックパスの記述ミス
今後の課題
- オートスケーリング
- ビルド、コンテナ起動の高速化
- Fargate の検討
- マイクロサービス化（App Meshなど）
まとめ
Meguro.dev で開発者向けのイベントが行われていたことは知っていたのですが、まさか福岡で同じようなイベントが開催されるとは思っていませんでした。数々の挑戦してきた話が聞けて良かったです。モブプロをやっている会もあるそうなので、引き続き開催されるようにできる範囲で協力していきたいです！
35
