https://irettechlabo.connpass.com/event/213923/

1. AWS & Google Cloud
を使った
システム開発/技術選定のはなし
アイレット株式会社 高橋修一

2. 高橋 修一
Shuichi Takahashi
所属：MSP開発セクション＠大阪オフィス(在宅勤務)
属性：開発エンジニア
役割：グループリーダー・iretシニアスペシャリスト
クラウド：
AWS: 2021 APN AWS Ambassadors、ALL AWS Certifications
Google Cloud: 5 certifications
自己紹介
趣味：散歩、ゲーム、筋トレ
出身：京都

3. 今日する話

4. 今日する話
システム
✨ベストプラクティス✨
開発
知見
活用
① ベストプラクティス
概要と活用方法紹介 ② 知見の共有

5. アジェンダ
• 背景=私のポジション
• ベストプラクティス
• AWS
• Google Cloud
• 知見の共有
• 基本的な考え
• サービスの特徴を理解する
• 意識していること・工夫
• 終わりに

6. 背景
=私のポジション

7. 構築・２次運用 お客様
MSP運用
お客様環境
MSP社内サービス
(サービス数:18)
MSP開
発
利用・操作認証
情報取得・操作
利用
依頼・要望・FB
ヒアリング・提案
開発・運用保守
構築・監視運用保守
ここ
MSP開発
運用や構築を効率化・一部自動化する社内サービスを開発・運用している部署
課題管理
外部サービス

8. アジェンダ
• 背景=私のポジション
• ベストプラクティス
• AWS
• Google Cloud
• 知見の共有
• 基本的な考え
• サービスの特徴を理解する
• 意識していること・工夫
• 終わりに

9. Well-Architected

10. クラウドアーキテクチャのベストプラクティス
フレームワークの 5 本の柱
• 運用上の優秀性(OPS)
• セキュリティ(SEC)
• 信頼性(REL)
• パフォーマンス効率(PERF)
• コスト最適化(COST)
• 設計原則
• 運用をコードとして実行する
• 小規模かつ可逆的な変更を頻繁に行う
…
• 分野
• 組織
• 準備
…
• ベストプラクティス
• 組織
• OPS 1: 優先順位はどのように決定すればよいでしょうか?
• 外部顧客/内部顧客のニーズを評価する
• ガバナンス要件/コンプライアンス要件を評価する
• 改善計画:AWS Trusted Advisor による脅威の状況評価
…
https://wa.aws.amazon.com/index.ja.html

11. いくつかピックアップ

12. ソリューションの選択
• PERF 2: コンピューティングはどのように選択するのですか?
• 使用可能なコンピューティングオプションを評価する(インスタンス、コンテナ、関数(FaaS))
• 利用可能な伸縮性のあるリソースを使用する
• メトリクスに基づいてコンピューティングニーズを再評価する
• PERF 3: ストレージソリューションをどのように選択していますか?
• ストレージ特性と要件を理解する
• 利用可能な設定オプションを評価する
• アクセスパターンとメトリクスに基づいて意思決定を行う
• REL 1:サービスクォータと制約はどのように管理しますか?
• サービスクォータと制約を認識する
• アーキテクチャを通じて、固定サービスクォータと制約に対応する

13. 具体的な提案
• REL 9: データはどのようにバックアップするのですか?
RTOとRPOの要件を満たすように、データ、アプリケーション、設定をバックアップします。
• ソリューション別のバックアップ方法
• EBS スナップショット、AWS Backup(EFS), RDS スナップショット
• DynamoDBオンデマンドバックアップ、ポイントインタイムリカバリ
• ソリューション別の暗号化オプション
• データバックアップを自動的に実行する
• AWS Backupによるスケジューリング
• Step Functionsによるバックアッププロセスの自動化(具体的なテンプレートなどは無し)
• データ復旧
• Step Functionsによる復旧プロセスの自動化(具体的なテンプレートなどは無し)

14. 定期的な見直し
• OPS設計原則:運用手順を定期的に改善する
• 定期的にゲームデーを計画し、すべての手順が効果的で、チームがその手
順を熟知していることを確認および検証します。
• COST 10: 新しいサービスをどのように評価していますか？
例えば
• 請求の10% 以上の価値を持つコアワークロードは四半期ごとにレビュー
• 請求の10% 未満のワークロードは年に 1 回レビューする

15. Well-Architected ツール
Well-Architectedのベストプラクティスに沿っているか
自分でチェック・レビューするためのツール
マネジメントコンソールからアクセス可能

16. しばらく使ってみて
• 新規システム
• 考慮漏れの予防になる
• 既存システム
• 課題解決のヒント、気づき
• システム自体に手を入れにくいケースでも、手順のコード化やドキュメント整理に
• AWS以外でも
• GoogleCloudで構築しているシステムにもWell-Architectedレビューか
けています
• 「チーム」の計画や習慣の見直しになる
• 定期的な分析の機会、タスクの進め方 → チーム自体の改善
• ドキュメントが整備されてきている
• Well-Architectedが出た頃よりドキュメントが充実してきていてる

17. 組織やチームに当てはめてみる
社内標準フロー
社内システム
契約している
SaaS
社内標準ルール
チーム内
運用

18. アジェンダ
• 背景=私のポジション
• ベストプラクティス
• AWS
• Google Cloud
• 知見の共有
• 基本的な考え
• サービスの特徴を理解する
• 意識していること・工夫
• 終わりに

19. Cloud アーキテクチャセンター

20. Cloud アーキテクチャセンター
https://cloud.google.com/architecture/framework
アーキテクチャ フレームワーク
システム設計の原則
• 卓越した運用
• セキュリティ、プライバシー、コン
プライアンス
• 信頼性
• パフォーマンスと費用の最適化
リファレンスアーキテクチャ
カテゴリやサービスでアーキテクチャを検索できる
https://cloud.google.com/architecture

21. ソリューションデザインパターン

22. デザインパターン
• 概要
• 解決する問題
• アーキテクチャ
• 機能要件 / 非機能要件
• メリット
• 注意事項
• 推奨設定
• 事例
• 参照ドキュメント
Google Cloudソリューションデザインパターン
https://events.withgoogle.com/solution-design-pattern/
各種ワークロード
• 共通ソリューソン
• エンタープライズ
• アプリケーション/データモダナイ
ゼーション
• クラウドネイティブ アプリケーション
• インフラストラクチャ / データベー
ス / ネットワーク
• データプラットフォーム（分析/AI)
• 業界別ソリューション
• ゲーム
• 流通・小売
• 公共機関

23. • 2020/12 にできたページ
• 「いろいろ検証してたどり着いたこと、ここに書いてあるやん」
例：クラウドネイティブ アプリケーション
• https://events.withgoogle.com/solution-design-pattern-app-
modernization-database-modernization/cloud-native-applications
Google Cloudソリューションデザインパターン

24. アジェンダ
• 背景=私のポジション
• ベストプラクティス
• AWS
• Google Cloud
• 知見の共有
• 基本的な考え
• サービスの特徴を理解する
• 意識していること・工夫
• 終わりに

25. 基本的な考え方
できるだけマネージドなものを使う
・AWSであればEC2よりもFargateやLambdaなど。
・Google CloudであればGCEよりもCloud Run、Cloud Functionsなど。
3rdのSaaSやソフトも活用
・New Relic、PagerDuty、Slack、Twilio、Terraformなどなど
→こちらで担保すべき範囲を減らし、開発の高速化↑/保守コストの低下↓
etc.

26. AWS / Google Cloud / 3rd
AWS Google Cloud 3rd
CI/CD Code Pipeline
Code Build
Code Deploy
Cloud Build Circle CI
Travis CI
GitHub Actions
IaC Cloud Formation
SAM
CDK
Deployment Manager Terraform
severless
監視・モニタリング Cloud Watch
X-Ray
Cloud Monitoring
Cloud Trace
Cloud Profiler
New Relic
Datadog
Mackerel
例
これらを組み合わせて利用することも可能
例) CI/CDでパイプラインはCircle CIを使い、デプロイはCode Deployを呼び出す

27. 3rdの活用
メインのアーキテクチャは
AWS、Google Cloudのサービスで構成
デプロイや監視・モニタリングなどは
3rdを活用することがいです
デプロイ
監視
テスト

28. 3rdのメリット
• AWSでもGoogle Cloudでも、同じ方法で対応できる。
• 習得コストが低く抑えられ、保守体勢も組みやすい
• 機能が豊富、痒いところに手が届く。
• ユーザーが自由に拡張機能を公開・共有できるものが多い

29. クラウドベンダーサービスのメリット
• クラウド内のサービス連携が強い
• 権限やユーザーの管理がIAMで完結
• 別途キーの管理やユーザー管理を考えなくていい
• 利用料金がクラウドサービス内で完結する
• 別途プラン選択や料金管理を考えなくていい

30. アジェンダ
• 背景=私のポジション
• ベストプラクティス
• AWS
• Google Cloud
• 知見の共有
• 基本的な考え
• サービスの特徴を理解する
• 意識していること・工夫
• 終わりに

31. 制約の確認
どのサービスを使うにしても「制約/割り当て上限」は確認。
設計段階で把握が漏れていると
あとあとかなり困る

32. 制約の確認
割り当て(クオータ)の確認
例
• FaaSの同時実行可能数
• FaaSのタイムアウト上限
• 作成できるリソース数上限
• 受けられるリクエスト数(req/sec)
・サービスエンドポイントとクォータ
・各サービスのクォータページ
・各サービス「割り当てと上限」
・例 Cloud Run
✅ 割り当ての単位は？ リージョン？グローバル？
✅ 上限の引き上げが可能？不可？
✅ 割当についてもアップデートで上限があがることがある

33. 制約の確認
特性の把握
例
• イベント配信
• 重複配信される？ １回のみ？１回以上(At least once)？
• 配信の順番は？FIFO？順不動？
• データ更新
• 結果整合性？強い整合性？
• 料金のかかり方
• 何に対して、何に比例して料金がかかる？
これらの制約もアップデートされることがある
(例)2020年12月 S3の全ての操作が「強い整合性」に

34. メトリクスから知る
どのようなメトリクス(指標)やログが
「CloudWatch(AWS)」や「Cloud Monitoring(Google Cloud)」に
出力されるかを知るとサービスの理解や考慮の気づきになることが多い
• CloudWatch メトリクスを発行する
AWS のサービス
・各サービスの「ロギングとモニタリング」
・例 Cloud Functions
例
• 同時実行数
• 失敗/エラー/スロットリング
• 実行時間
• メモリ使用量
• 各種I/O
• キュー数
• レイテンシ
• 処理数/バイト数

35. アジェンダ
• 背景=私のポジション
• ベストプラクティス
• AWS
• Google Cloud
• 知見の共有
• 基本的な考え
• サービスの特徴を理解する
• 意識していること・工夫
• 終わりに

36. IaCで気をつけていること
コンソール画面では様々な設定が自動で行われる
IaCにしたとき、普段意識しない設定が漏れていないか？
・S3バケットの暗号化有効になっている？（明示的に記載必要）
・API GatewayのAPIキー生成して、APIキー必須フラグはついてる？
・LambdaをCWで呼び出すときにLambda側にパーミッションつけてる？
注意：制限を運用中に強化するのは内容を理解し動作検証したうえで行わないと事故の元。
経験、レビュー、テストだけで拾おうとすると漏れが怖い
・AWS Config、AWS Trusted Advisor
・Cloud Recommender

37. 事故の防止
環境間違いの防止
• 環境ごとにアカウント(AWS)/プロジェクト(GoogleCloud)をわ
ける
• アカウント/プロジェクトに連動してUIの色が変わるブラウザ
拡張などを使う
• リソース名の先頭を「ステージ名」に
(例) {ステージ名}-{マイクロサービス名}-{役割名}
• dev-ServiceA-Xrunner
• stg-ServiceA-Xrunner
• prd-ServiceA-Xrunner

38. 選定理由を残しておく
• 設計資料として残す
• Wikiに選定理由を残す。(ディシジョンレコード)
• アーキテクチャ図にコメントで残しておく
• Slackのpublicな独り言チャンネルに垂れ流し
• 他の人の発言を検索でひっかけ役立つこともあるのでpublicで！
見直しをかけるときや、類似するアーキテクチャを検討するときに役立つ。
アップデートで制限が緩和されたり撤廃されることもあるので、当時の手
がかりがあると助かる。

39. EOLやアップデート追従の管理
言語やフレームワークのサポート期限、推奨APIバージョンの変更など
計画的に対応する必要がある。
現状：スプレッドシートで一覧にし、月１定期で対象や状況を見直し。
という泥臭い方法でやってます。「こんな感じでやってるよ〜」とかあればコメントもら
えると助かります！

40. アジェンダ
• 背景=私のポジション
• ベストプラクティス
• AWS
• Google Cloud
• 知見の共有
• 基本的な考え
• サービスの特徴を理解する
• 意識していること・工夫
• 終わりに

41. メンバー募集してます！
運用業務の自動化・効率化を実現するシステムの開発に興味がある方
で「MSP開発チーム」とお話しましょう
お申し込みはこちら → https://cloudpack.jp/recruit/
または「cloudpack 採用」で検索ください！
カジュアル面談
まずは
41

42. ご清聴ありがとうございました
Next！
ディスカッション・Q&A

43. 自己紹介
所属 : クラウドインテグレーション事業部 MSP開発セクション@大阪オフィス
役割 : 開発エンジニア・iretシニアスペシャリスト
2018/04 入社
AWSを中心とした設計・構築やバックエンド開発
社内の監視業務の改善・効率化に従事
2021 AWS APN Top Engineers
山﨑 慎太郎
Shintaro Yamasaki

44. ディスカッション
• 技術選定に絡めての体験談
(成功/失敗など)
• AWS と Google Cloud 両方を使うチームで働いてみて
(メリット/苦労したこと)

45. Q & A
• AWSとGoogle Cloudどのように使い分けていますか？
• これは便利だと思うAWSとGoogle Cloudのサービスを
教えてください！