Developers.IO 2018 メモまとめ
メモをまとめました。
1000件以上の活用を見てわかった絶対に失敗しないAWSベストプラクティス
https://www.slideshare.net/skikuchi/developersio-2018-tokyo-aws
AWS W-A Framework
・設計原則と質問形式のAWSのベストプラクティス集
・今回は、W-Aに沿ってノウハウを紹介
セキュリティ
・すべてのメンバーに、セキュリティに対する責任がある
・保護の対象は、AWSアカウント、システム、データ。システムとデータの保護は、オンプレと同じ
・AWSアカウントのセキュリティがあらたに追加されるイメージ
・Insight Watchを使えば、セキュリティ設定の自動チェックができる
・Amazon Guard Dutyを使えば、機械学習による異常な振る舞いを検知できる
信頼性
・Design for Failure。故障することを前提に、設計する
ディザスタリカバリのパターン
・別リージョンのS3にバックアップを取得
・パイロットライト：AMIを別リージョンにコピー。なにあったら、CloudFormationでAMIからEC2を作成
・ウォームスタンバイ：平常時は、別リージョンに最小限のリソースで立ち上げて同期しておき、非常時にスケール
・マルチサイト：常時、複数リージョンを使ってサービスを提供
パフォーマンス
・NITRO SYSTEMへの移行
・ベアメタルインスタンス（448vCPU、12TB Mem、Tokyoリージョンサポート）の利用
・用途に応じた、正しいマネージドDBを選択
コスト
・マネージドサービスを利用
ーAPIゲートウェイ＋Lambda -> REST API
ーAppSync GraphQL API
・スポットインスタンスの活用
ー価格高騰時の「停止」サポート（従来は、「削除」）
ー価格変動がなだらかに
運用
・自動化が基本
・SystemManager、Code4兄弟の活用
継続的な環境の改善（KPIの改善）
・新サービスの機能、サービスの新機能を取り込んでいく
・AWSのサービスは、最小の機能でリリースされ継続的に機能が追加されていくことを意識する
基礎から応用までじっくり学ぶ「AWSでのネットワークの作り方」
VPC
・自社で利用しているIPアドレスは避ける
・1VPC /16がお薦め
・IPアドレスを固定するより、DNS名でアクセスするようにしたほうが良い
Subnet
・3層構造がお薦め（インターネットアクセス層、WebAP層、DB層）
・3 AZ * 3 層 = 9 Subnet
・インターネットに接続しないので、2層にするなどのアレンジしても良い
・1Subnet /24がお薦め。
NATゲートウェイ
・AZ毎に1つ必要なので注意
通信制御
・ネットワークACLは、特定のIPアドレスからの接続を拒否したい時に利用
VPCの分割
・AWSのアカウントの分割も検討。特に、他社がアクセスする環境は、別アカウントにしたほうが良い
・VPC同士は、VPCピアリングでくっつけられる
VPCピアリングの注意点
・IPアドレスの重複
・DX（Direct Connect） -> VPC -> VPCは、NG
・VPC -> VPC -> Internetは、NG
ELB
・ALB、CLB、NLBで、機能差があることに留意
・NLBは、1アーム構成。EIPがもてる。戻りパケットは、EC2から直にいく。そのため、戻りアドレスは変わる
NLBの応用
・NLBとPrivate Linkを使って、他社のAWSの内のインスタンス内にインターネットを経由することなく接続できるようになった
DX
・キャリアに頼るのが良い
・共有型を使うのが一般的
マネージド（ハードウェア）VPN
・10拠点まで
・カスタマーGWは、FAQに書いてあるルータを使うがお薦め
ソフトウェアVPN
・多拠点接続するときは、運用が大変なので、キャリアのサービスの利用も検討する
・MarketplaceからEC2を建てる。時間課金（サポートがUSなので注意）かBYOL
Amazonの文化をハックせよ。100万円未満で無人レジの仕組みを作ってみた 〜横田deGoプロジェクト〜
https://speakerdeck.com/satoshi7/developersio2018heng-tian-degosisun2
作戦
・得意なところ（AWS、モバイル）はササッと済ませ、やったことがないところ（工作や設置）に時間をかけよう
要件
・ビデオを作成して、体験を共有（しただけ）
各種センサーの利用
・棚の重量検知、3D LiDAR、深度（棚に入れる手の動き）
・映像だけで、人間の動きをトレースするのは限界があるのではないか
機械学習
・商品判定に利用
・SargeMaker＋nVideaのHW＋GreenGlass
やってみてわかったこと
・今後は、エンジニアだけではだめで、総力戦の時代になる
・AWSが研究成果をソフトウェアとして、提供してくれるので、いかに組み合わせるかが重要
知って備えれば怖くない！ AWS移行ガイド
https://speakerdeck.com/kmd2kmd/developers-io-2018-zhi-tutebei-erehabu-kunai-awsyi-xing-kaito
大事なこと
・移行する目的を明確にする
一般的なクラウド移行の目的
・耐障害性
・運用負荷の低減
・コストダウン
・イノベーションの加速
・ビジネスの俊敏性 ★AWSに移行したユーザーの大半の目的がこれ
クラウド化への道のり
・1つのプロジェクトでAWSを使用
・共通基盤（Active Directory、WSUSなど）のクラウド化を検討
・クラウドネイティブでアプリを再設計、移行 or 既存アプリの単純移行、クラウド最適化
6つの移行戦略
・Rehost(Rift & Shift)：システムをオンプレの方式そのままで、AWS上に移行もしくは構築
・Replatform(Rift -> Modify -> Shift)：システムの一部をマネージドサービスを用いてクラウドに最適化。ただし、アプリには手を入れない
・Repurchase：AWSではなくSaaSに移行
・Refactor：システム全体をクラウドに最適化。アプリにも手を入れる
・Retire：オンプレのまま廃止を待つ
・Retain：クラウドへの移行が困難、または、リプレースしたばかりなのでそのままにしておく
メモ
・Amazon Linux：RHELベース。AWS環境に最適化
クラウドの仲間を増やす
・AWSアカウントと時間を与える
体制づくり
・既存SIer：既存アプリケーションを担当
・自社：プロジェクト管理
・クラウドベンダー：AWS
移行のためのツール
・AWS Application Discovery Service
・（他）
AWSのセキュリティ設定がどうなっているか抜け漏れなくちゃんと確認する方法
AWSが提供するセキュリティ系のサービス・機能
・Amazon Inspector：EC2インスタンスのセキュリティをチェック
・（他）
Insightwatch
・CloudMethodが提供するサービス
・CISベンチマーク、AWSセキュリティチェックリストに基づくセキュリティを確認
・ジョブ（EBSスナップショットの取得など）の実行もサポート
・米国CISの認定プロダクト
・CIS Amazon Web Services Foundation Benchmark 1.1.0サポート（最新は1.2）
セキュリティ対策
・どのようなセキュリティ対策をする／しないを選択するには、セキュリティエンジニアが必要
徳丸さんの特別講演
・インシデントの大半の原因は、認証・許可、ソフトウェアのバグ（脆弱性）
・質問サイトをウォッチ、回答している
ーYahoo知恵袋
ーTeratail
ーStackoverflow
・ソフトウェアを発注するときは、検収する事が重要
・セキュリティに関しては、セキュリティコンサルを使うのも手
・弊社では、設計書のレビューもしている
・最近は、セキュリティの内製化がホット。アジャイルやDevOpsで進める場合、デプロイの都度、セキュリティベンダーに見てもってられないため
QA
Q：自社でセキュリティを内製化するにはどうしたらよいか？
A：教育->レビュー->脆弱性診断->規定の作成、という順で進めるのがお薦め。IPAやOWASPの資料が参考になる。規定など定期的に更新することが重要
Q：脆弱性診断の頻度はどうすればよいか？
A：原理的には、デプロイ時に手を入れたところだけをテストする。ただ、現実的には３ヶ月に１回程度になってしまっているところが多い
ビジネスを阻害しない！AWSアカウントのID・権限管理について
（知っていることが多かったのメモ少なめ）
MFA
・Yubiキーサポート。USBに挿して指をタッチして認証することができる
IAMベストプラクティス（15個ある）
・利用すれば効率的にユーザー管理の設計が可能。ただし、原理主義は禁物
・Cloud TrailでAPI Callを記録（ConfigもAPI Callを記録）。監査ログを改ざんできない設定する
・強い権限を持つIAMユーザーにMFAを矯正させるポリシーをかける
5つのユースケースから理解するAWSのデータベースサービスの勘所
https://speakerdeck.com/maroon1st/awsfalsedetabesusabisufalsekan-suo-5tufalseyusukesukarali-jie-suru
AWSが提供するデータベースサービス
・Neptune：グラフDB。SNSのつながりを保存。使い所の判断が難しい
・IoT Analytics：IoTデータを保存できる
・（他多数）
一般的なWebサービス
・Aurora（ユーザーデータ）＋ElasticCache（セッションデータ）
・Auroraの限界にぶち当たったらDynamoDBの利用を検討
サーバレス
・Dynamo
・Lambdaは、コネクションションプールがないのでRDBではきつい
・Lambdaから、VPCのRDSなどへの初回アクセスは、ENIを作るため遅い（10から30秒程度かかる）
DWH
・Data Migration ServiceをETLツールとして利用することができる
・TB～PBクラスのデータ分析には、RDBは向かない
・Redshift、またはAthenaを利用。
・分析は、Tablaueがお薦め。AWSサービスだとRedshift Spectrumというのがある
＜参考＞
Auroraの新機能であるPararellQueryに関しては、後日検証して結果を公開する予定
IoT
・書き込み多く読み取り少い、かつ、時系列データのためRDBは向かない
・IoT Analyticsがお薦め。AWS QuicksightやJupyter Notebookで分析が可能
レコメンデーション
・協調フィルタリングなどのデータは、RDBには向かない
・そもそもレコメンド用のデータをDBに入れている事例は少ない
・Neptuneを使った実験をしてみた
まとめ
「金のハンマー」は持たないように気をつける。⇒なんでもかんでも、得意なDBに入れようとせず、適材適所の選択をする
この記事が気に入ったらサポートをしてみませんか？