nokoのブログ

こちらは暫定のメモ置き場ですので悪しからず

システム構築案件が立ち上がったときにインフラ担当としてやっていること

技術全般

はじめに

システム構築案件が立ち上がったときにインフラ担当としてまずやっていることをメモしました。抜け漏れはあります。

やったこと

1. スケジュール・マイルストーン確認

  • マスタスケジュール
    • 他システム、アプリ含めたスケジュール
    • → 全体の整合性を確認
  • インフラ構築スケジュール
    • 顧客、関連ベンダ含めた役割分担を認識合わせするため
      • 特にテストフェーズ
        • 仕様書作成
        • 環境構築
        • テスト実施
        • テスト結果レビュー、etc
    • マイルストーン確認
      • 対顧客、対アプリチーム
      • アプリチームへの環境引き渡しタイミングなど
    • 環境利用計画確認
      • 何面作ることになるか。いつまでに必要か。
  • → いつ誰が何をやるか、明確に

2. 成果物確認

  • 非機能要件定義書
    • 基礎数値表等
  • インフラ基本設計書
    • システム化方針
    • 全体システム俯瞰
    • アーキテクチャ構成
    • ネットワーク構成
    • ハードウェア構成
    • ソフトウェア構成
    • 処理方式概要
    • 製品・技術要素選定根拠
  • 監視設定一覧
    • 死活監視
    • ログ監視
    • リソース監視
  • バックアップ・リストア・改廃設定一覧（運用設定書）
  • 運用設計書
    • システム概要（サービス対象範囲）
    • 運用体制
    • 運用方針（サービス時間等）
    • 運用業務詳細
  • 運用作業手順書
    • リソース拡張
    • 監視設定追加・非監視設定
    • デプロイ
    • リストア
  • 非機能テスト仕様書
    • （インフラ単体テスト）
      • パラメタ設定
      • 起動停止
      • 基本機能提供
    • （インフラ結合テスト）
      • 業務処理通信
      • 運用処理通信
      • バックアップ改廃
      • アラート
      • 耐障害性
    • （セキュリティテスト）
    • 障害テスト
      • 可用性テスト
      • 監視通知テスト
    • 性能テスト
      • 負荷テスト
      • 限界テスト
      • 耐久テスト
    • （運用テスト）
      • キャパシティ管理
      • システムメンテナンス
      • システム監視
      • データ抽出
      • バックアップリストア
      • リリース
      • ログ管理
      • 障害対応
      • 定常作業
  • ソース

3. 直近のタスク確認

ヒアリング事項整理

  • 役割分担、制約条件をまず確認する

役割分担

  • Who: 担当者、関連ベンダ確認
  • Where, How: 作業担当スコープ整理+環境アクセス方法・モジュール連携方法確認
    • アカウント契約
    • DX契約
    • 構築作業
  • When: マイルストーン確認

制約条件

4. wiki整備（内部向け）

  • アプリ担当者向け
    • 環境構成図
    • 接続情報
    • 障害対応手順
  • インフラ担当者向け
    • 開発規約
    • ネットワーク
    • セキュリティ
    • デプロイ
    • 監視
    • バックアップ・リストア・改廃
    • テスト
    • 運用

5. WBS作成

  • 非機能要件定義作成
  • インフラ基本設計書作成
  • アカウント作成
  • ストレージ
  • ネットワーク
  • ルーティング
  • サービス
  • データストア
  • 運用環境（デプロイ）
  • 運用環境（セキュリティ）
  • 運用環境（監視）
  • 運用環境（バックアップ・リストア・改廃）
  • インフラ単体テスト
  • インフラ結合テスト
  • 性能テスト
  • 障害テスト
  • 運用テスト
  • 運用設計書作成
  • 運用作業手順書作成
  • 運用引き継ぎ

インフラエンジニアとしての心構え

  • システム（環境）全体を見れる立場から、早めにリスクを検知して潰し込み、リリースに着地させる義務がある
    • プロジェクトは想定通り行かない。想定外の事象が発生したときに、影響調査をして、誰がいつ何をすべきかを整理してインプットしていく。
    • 浮いてるタスクを検知し、論点を明確にした上で選択肢とメリデメを提示&ポジションを取る。

参考

ABC132-D_RedandBlueBallsをpythonで解いた（場合の数）

競プロ

問題

考え方

f:id:noko_htn:20200516212401j:plain

ポイント

解法

n, k = map(int,input().split())


MOD=10**9+7
def comb(n,k):
    if n<k:
        return 0
    if n<0 or k<0:
        return 0
    k=min(n-k,k)
    ans=1
    inv=[1]*(k+1)
    if k>=1:
        ans*=(n-k+1)%MOD
    for i in range(2,k+1):
        inv[i]=MOD-inv[MOD%i]*(MOD//i)%MOD
        ans=ans*(n-k+i)*inv[i]%MOD
    return ans


for i in range(1, k+1):
    ans_i = comb(n-k+1, i) * comb(k-1, i-1)
    print(ans_i % MOD)

ABC167-D_Teleporterをpythonで解いた（その他）

競プロ

問題

考え方

f:id:noko_htn:20200516193627j:plain

ポイント

  • 考察大事。サンプルを書き出す。
  • flag系は、はじめにリストを用意しておく
    • seen = [-1]*(n+1)
  • indexと○個目の対応は、メモを書きながらミスらないようにする
    • a_list = [0] + list(map(int,input().split()))
    • roop_end_index = len(town_hist_list) - 1

解法

n,k = map(int,input().split())
a_list = [0] + list(map(int,input().split()))

town_num_tmp = 1  # 今いる町
seen = [-1]*(n+1) # indexの街に訪れたことがあるか（訪れたことがない: -1）
town_hist_list = []

while seen[town_num_tmp] == -1:
    seen[town_num_tmp] = 1
    town_hist_list.append(town_num_tmp)
    # 更新
    town_num_tmp = a_list[town_num_tmp]

roop_end_index = len(town_hist_list) - 1
roop_start_index = town_hist_list.index(town_num_tmp)
roop_range = roop_end_index - roop_start_index + 1

if k < roop_end_index:
    print(town_hist_list[k])
else:
    print(town_hist_list[(k-roop_start_index)%roop_range+roop_start_index])

AWSCertifiedSysOpsAdministrator–Associate取得に向けて勉強したこと

資格

はじめに

AWSCertifiedSysOpsAdministrator–Associate取得に向けて勉強したことのメモです。

やったこと

  • whizlab

メモ

VPC

  • IPv6
    • デフォルトでパブリック。NAT gatewayではなく、egress-only Internet gateway
    • デュアルスタックモード
      • 既存の VPC が IPv4 のみに対応しており、サブネット内のリソースが IPv4 のみを使用するように設定されている場合は、既存の VPC とリソースに対して IPv6 を有効化できます。VPC は、IPv4 または IPv6 あるいは両方を経由して通信できます。（デュアルスタックモード）IPv4 と IPv6 は、互いに独立して通信されます。
  • IGWを作った後にルートテーブルの設定追加を忘れない（0.0.0.0/0）
  • ネットワークACL
    • セキュリティグループでは出来なかった「特定のIPアドレスを拒否する」ことが可能
  • VPC の DNS サポート
    • デフォルト以外の VPC 内にインスタンスを起動すると、プライベート DNS ホスト名がインスタンスに割り当てられ、VPC に指定した DNS 属性に応じて、およびインスタンスにパブリック IPv4 アドレスがある場合、パブリック DNS ホスト名が割り当てられる可能性があります。
    • VPC には、VPC 内で起動したインスタンスがパブリック IP アドレスに対応するパブリック DNS ホスト名を受け取るかどうか、および Amazon DNS サーバーを通じた DNS 解決が VPC に対してサポートされるかどうかを決定する属性があります。
      • enableDnsHostnames: パブリック IP アドレスを持つインスタンスが、対応するパブリック DNS ホスト名を取得するかどうか
        • この属性が true の場合、VPC 内のインスタンスは DNS ホスト名を取得しますが、これは enableDnsSupport 属性も true に設定されている場合のみです。
      • enableDnsSupport: DNS 解決がサポートされているかどうかを示します。
        • この属性が true の場合、Amazon が提供する DNS サーバー (IP アドレス 169.254.169.253) へのクエリ、またはリザーブド IP アドレス (VPC IPv4 ネットワークの範囲に 2 をプラスしたアドレス) へのクエリは成功します。
  • subnetの設定で、自動でEC2インスタンスにGIPを振るかどうかを決められる
  • VPCフローログ
    • LogDestinationPermissionIssueException
      • Amazon S3 バケットポリシーの制限の超過
      • Amazon S3 バケットに発行するフローログを作成するたびに、指定されたバケットの ARN (フォルダパスを含む) がバケットのポリシーの Resource 要素に自動的に追加されます。
      • 一方、Amazon S3 バケットポリシーのサイズは 20 KB に制限されています。
      • 対策としては、個々のフローログエントリを以下で置き換えて、バケット全体にアクセス権限を付与する。

AWS Direct Connect

CloudFront

EC2

  • DBを組む場合
    • RAID0: ストライピング
    • RAID1: ミラーリング
    • RAID5: パリティ分散
    • RAID10: RAID1でミラーリングされたディスクのセットを複数用意して、それらの間でストライピング(RAID0)します。
    • RAID6: データからパリティを2つ生成し、データとともに分散して書き込みます。

ELB

  • 内部 Classic Load Balancers
  • ヘルスチェック
    • 5秒間隔pingなど
  • SurgeQueueLength
    • ELBは、バックエンドインスタンスがリクエストの処理能力を超えた場合に備えて、surge queueという待ち行列を備えています。
    • 例えば、EC2インスタンス上のApache httpdのMaxClientsが飽和し、新たなコネクションを受け付けられない時、ELBはリクエストを一旦このキューに格納し、バッファリングを行います。

CloudWatch

  • オンプレでも収集可能
    • CloudWatch エージェントを使用して Amazon EC2 インスタンスとオンプレミスサーバーからメトリクスとログを収集する
    • Windows Serverの場合、statsDを併用したり（CloudWatch Agentに組み込まれているので、有効化する）
      • statsD: OSSの数値レポーティングツール。collectd的な。
  • Metric Math を使用する
    • Metric Math により複数の CloudWatch メトリクスをクエリし、数式を使用して、これらのメトリクスに基づく新しい時系列を作成できます。作成された時系列を CloudWatch コンソールで視覚化でき、ダッシュボードに追加できます。AWS Lambda メトリクスを例として使用すると、Errors メトリクスを Invocations メトリクスで除算してエラー率を得ることができます。
    • EFSのTotal IO Bytesなど

WAF

  • https://dev.classmethod.jp/articles/aws-relearning2019-aws-waf/
  • WAF全般のこと
    • WAFに期待される主な働きは、悪意のある通信をブロックし、悪意のない通信を許可することです。実際に可能な動作は、通信がWAFを通過する時にルールに一致する場合はブロックまたは許可するものです。
  • AWS WAFの基本
    • AWS WAFはALB、CloudFront、API Gatewayに割り当てて利用します。
    • ルールには番号があり小さい順番に評価され、一致した時点でそのルールが適用されます。不審な通信をルールでブロックし、ルールに一致しない通信は許可することが多いです。
    • AWS WAFでブロックすると、403の素っ気ないエラー画面が表示されます。ユーザーが用意したカスタムエラーページを表示するには、CloudFrontが必要です。
  • AWS WAFで作成できるルールは4種類に分けられます。

Amazon GuardDuty

  • https://dev.classmethod.jp/articles/guardduty-summary/
  • GuardDutyとは
    • AWS環境のセキュリティを継続的にチェックしてくれる
    • 各種ログを自動的に取得して、機械学習で分析して異常を通知してくれる
    • 使用方法は有効化するだけ
      • -> 有効化したあとは、何かあればCloudWatch EventとSNSを介して通知が飛びます。
  • セキュリティリスク
    • インターネット上のリソースに対する攻撃リスク
      • -> GuardDuty で独自の信頼された IP リストや脅威リストも使用するように設定することでカスタマイズできます。
    • AWSアカウントへの攻撃リスク
      • 具体的にはIAMのクレデンシャル情報
  • GuardDutyの原理と動作
    • 各種AWSのログを収集している
      • CloudTrailのイベントログ, VPC Flow Logs, DNSログ
      • ログを機械学習とAIで分析している

Amazon Inspector

  • 【Amazon Inspector とは？】初心者にもわかりやすく解説
  • AWSのEC2 インスタンスにおいて脆弱性診断を自動で行ってくれるサービス
  • 脆弱性診断を行うメリットとしては、実際のサーバに疑似的なサイバー攻撃を仕掛けることによって、本物のサイバー被害を受けることなくセキュリティのリスクを発見できる
  • ただし、評価をするだけで脆弱性の対処はできません。
  • Amazon Inspector と Amazon GuardDuty の違い
    • Amazon Inspector と Amazon GuardDuty の違いは、前者は「実際に攻撃を受けるとどうなるかをチェックする」もの、後者は「実際のログを分析して脅威が存在するかをチェックする」ものです。
    • Amazon Inspectorの目的は、対象AWSにおいてよくあるセキュリティリスクに対処できているかをテストすることです。
    • つまり、「運用中のEC2でもしもAのような攻撃を受けたとしても問題ないような設定や仕様になっているか？」をチェックすることです。
    • 対して、Amazon GuardDutyは、運用しているAWSで実際に起こったイベントが分析対象です。
  • Network Reachability
    • EC2インスタンスがインターネット、仮想プライベートゲートウェイ、AWS Direct Connect、またはピアVPCなどの外部ネットワークから到達できるかどうかを判断するために、Amazon仮想プライベートクラウド（Amazon VPC）ネットワーク構成を分析します。
    • つまり、ホストへの外部アクセスの可能性を通知します。これは、セキュリティグループ、ネットワークアクセスコントロールリスト（ACL）、ルートテーブル、インターネットゲートウェイ（IGW）など、すべてのネットワーク構成をまとめて分析することで、到達可能性を推測します。
    • VPCネットワーク経由でパケットを送信する必要はなく、EC2インスタンスネットワークポートへの接続を試みる必要もありません。パケットレスネットワークマッピングや偵察のようなものです！
    • -> これで到達可能か（SGの設定変更が失敗してないか等）をチェックし、CloudWatch Event ruleで通知する
  • Inspector Agent が事前インストールされた AMI

AWS Trusted Advisor

  • AWS Trusted Advisorは、「コスト最適化」、「パフォーマンス」、「セキュリティ」、「フォールトトレーランス」の４つの観点から、利用者のAWS環境をAWSが自動で精査し、推奨設定のお知らせをしてくれる機能です。
    • EC2起動台数が制限台数以内に余裕を持って収まっているか

IAM

  • Granting a User Permissions to Pass a Role to an AWS Service
    • 多くの AWS サービスを設定するには、そのサービスに IAM ロールを渡す必要があります。これにより、サービスが後でロールの継承を行い、ユーザーの代わりにアクションを実行できるようになります。
    • サービスにロールを渡すのはセットアップ時の 1 回限りで、サービスがロールを継承するたびに行うのではありません。
    • たとえば、Amazon EC2 インスタンスで実行しているアプリケーションがあるとします。このアプリケーションには認証に使う一時的な認証情報と、AWS でアクションを実行するためのアプリケーション認証のアクセス許可が必要です。
    • -> アプリケーションをセットアップする場合、こうした認証情報を提供するインスタンスを使用するため、EC2 にロールを渡す必要があります。
    • -> そのロールに IAM ポリシーをアタッチして、インスタンスで実行するアプリケーションのアクセス許可を定義します。アプリケーションは、このロールが許可しているアクションを実行する必要があるたびに、ロールを引き受けます。
    • ユーザーがロール (とそのアクセス許可) を AWS サービスに渡すには、そのサービスにロールを渡すアクセス許可が必要になります。
    • -> これにより、承認済みのユーザーのみが、アクセス許可を付与するロールを使用してサービスを設定できるようになります。ユーザーが AWS サービスにロールを渡すには、IAM ユーザー、ロール、またはグループに PassRole アクセス許可を付与する必要があります。
  • AWS アカウントの認証情報レポートの取得
    • アカウントのすべてのユーザーと、ユーザーの各種認証情報 (パスワード、アクセスキー、MFA デバイスなど) のステータスが示された認証情報レポートを生成し、ダウンロードできます。
  • IAMポリシーを利用することでEC2作成時、タグの付与を強制することができる

AWS Organizations

  • https://qiita.com/atsumjp/items/57ce3cd17d78b5ac3df9
  • AWS Organizationsは大きく分けて、Payerをまとめる機能とSCPにより認可設定する機能があります。
  • SCPを付与する対象(エンティティ)は、組織のツリー構造のルートにあたるRootとOU（組織単位）とAWSアカウント
    • 組織単位 (OU): ルート内のアカウントのコンテナ。
  • SCP
    • SCPは組織に含まれる複数のAWSアカウントに対してざっくりとした権限制御を行うための仕組みです。
    • 多くのアカウントを管理するとき、権限制御については各AWSアカウントのIAMを設定する必要がありました
    • -> AWS OrganizationsのSCP(Service Control Policy)を利用することで、複数のAWSアカウントに対する権限の制御が可能になっています。
  • AWS Organizations 入門
    • 管理者として使用するAWSアカウントを一つ選び、組織を作る。
    • 選んだAWSアカウントはマスターアカウントとなり、組織の全体を管理する権限を持つ。
    • 組織内のマスターアカウント以外はメンバーアカウントとなる
    • 組織には複数AWSアカウントのグループ(OU)を作成できる。
    • OUにはAWSアカウントを作成、追加することができる。
    • OUからアカウントを削除した場合、アカウントは組織からは外れるが独立したたアカウントとなり、個別に請求などが開始される。アカウント自体が消されるわけではなく、使い続けれる。
    • OUの開始点は管理用ルートとなる。
    • 組織内の権限はポリシーで制御することができる。
    • サービスコントロールポリシー(SCP)はIAMと同じ構文ルールで登録する
    • 利用シーン
      • AWSの支払いを代行してほしい
      • プロジェクトの環境を本番、ステージング、開発の3つに分けて管理したいんだけど
      • 社員にAWSの検証環境を配布したい
      • 組織からアカウントを削除したら使えなくなる？
        • アカウント自体は削除されないので大丈夫です
        • アカウントが独立するので個別に請求されないように注意

AWS Systems Manager

  • AWS Systems Manager (SSM)はAWS上、オンプレミスに関係なくSSMエージェントが稼働するサーバインスタンスを一元管理するためのサービス。
  • AWSコンソールからオンプレサーバを操作することもできたり
  • ハイブリッド環境で AWS Systems Manager を設定する
    • ステップ 1: Systems Manager の一般的なセットアップステップを完了する
    • ステップ 2: ハイブリッド環境の IAM サービスロールを作成する
    • ステップ 3: オンプレミスサーバーおよび VM に TLS 証明書をインストールする
    • ステップ 4: ハイブリッド環境のマネージドインスタンスのアクティベーションを作成する
    • ステップ 5: ハイブリッド環境に SSM エージェント をインストールする (Windows)
    • ステップ 6: ハイブリッド環境に SSM エージェント をインストールする (Linux)
  • AWS Systems Manager ドキュメント
    • yamlのcommandsの部分に実行したいコマンドを記載
    • 依頼者と実行者が別、実行するタイミングが不明、履歴を残したい、コマンドにバグがあったら訂正も面倒、定期的に実行したいとかの場合もドキュメントとオートメーションは役に立つかと思います。
  • (オプション) プライベートクラウドエンドポントの作成
  • AWS Config Rules
    • SGでポートを空けているやつがないかどうかチェック
    • AWS Config ルールのトリガーの指定
      • アカウントにルールを追加する際に、AWS Config でルールを実行するタイミングを指定できます。これは、トリガーと呼ばれます。AWS Config では、トリガーが発生すると、ルールを適用してリソースの設定を評価します。
      • 2種類のトリガーがあります。
        • 設定変更
        • 定期的
      • 設定レコーダーがオフになっているときのルールの評価
        • 設定レコーダーをオフにすると、AWS Config ではリソースの設定変更の記録を停止します。これは以下のようにルールの評価ルールに影響します。
          • 定期的トリガーのルールは、引き続き指定した間隔で評価が実行されます。
          • 設定変更トリガーのルールでは、評価が実行されません。
          • 両方のトリガータイプのルールでは、指定した間隔でのみ評価が実行されます。設定変更のルールでは評価が実行されません。
          • 設定変更トリガーのルールのオンデマンド評価を実行すると、リソースの最後の知られている状態 (前回記録された設定項目) が評価されます。
  • Document: Systems Managerでいう「ドキュメント」とは、自動実行される内容（≓スクリプト）を表す
  • Patch Manager
    • パッチの自動適用や適用状況を集計する
    • S3に実行されたログを残す
      • S3バケットをVPCエンドポイント経由からのみアクセスできるようにするバケットポリシーを設定できる
        • VPCエンドポイントはVPC内部のリソースであればインターネットを経由せずにアクセス可能になる出入り口のようなものです。
  • AWS Config
    • Aggregate
    • 複数のリージョン、複数のアカウントのリソースを取得できる
    • 個別アカウントの承認処理は各リージョン毎に行う必要があるようです。ターゲットのアカウントで、各リージョンで AWS Config を有効化する都度、承認待ちになっていました。

S3

  • Amazon S3 Glacier
    • Amazon S3 Glacier (S3 Glacier) では、アーカイブを格納するコンテナをボールトと言います。
    • アーカイブとは、ボールトに格納する写真、動画、ドキュメントなどのオブジェクトを指します。
    • アーカイブは、S3 Glacier のストレージの基本単位です。
    • ボールトを作成し、アーカイブをアップロードおよびダウンロードした後、最後にアーカイブおよびボールトを削除します。
    • 「ロックポリシー」機能
      • https://dev.classmethod.jp/articles/introduce-to-write-once-read-many-lock-on-amazon-glacier/
      • Glacierに保存されたオブジェクトの書き換えや削除をAWSの機能として禁止させることができ、その期間も自由にポリシー設定することができるようになります。
      • -> AWSは色々な企業の情報も扱うことが多いわけですが、企業にはそれぞれ情報に関するポリシーやコンプライアンスが定められています。その中には「情報の保存」も厳しく定められている事も多く、その情報が「書き換えられていないこと」「削除されていないこと」を証明するためにCloudTrail、S3のバージョン管理などの証跡サービスを使ったりします。しかし金融業などではそもそも「書換不能」「消去不能」なフォーマットで情報を保存するべし、という規則が定められています。今回のロックポリシーはこのような「絶対に書き換えられない」「絶対に削除できない」ポリシーを適用することで企業コンプライアンスをクリアできる、という場合や多人数、社外の会社さんに運用を頼む時等に絶対にログを消さないで欲しい、というようなケースの場合に「消えた時どうするか」ではなく「そもそも消えない」という状況を作り出すために使います。
  • Amazon S3 サーバーアクセスのログ記録
    • サーバーアクセスのログには、バケットに対するリクエストの詳細が記録されます。サーバーアクセスのログは、多くのアプリケーションに役立ちます。
    • たとえば、アクセスのログ情報は、セキュリティやアクセスの監査に役立ちます。
    • ログ記録を有効にするには、以下を実行する必要があります。
  • S3のアクセスコントロール
    • https://dev.classmethod.jp/articles/s3-acl-wakewakame/
    • ACL
      • ACLの設定はバケット、もしくはオブジェクト単位で設定する事が出来るのが特徴
    • BucketPolicy
      • Action, Effect, Principal, Resourceと、これらを組み合わせて柔軟なアクセスコントロールが実現出来ます。
      • この一個のファイルだけを公開したいとかそういった用途に使うのには向いていないように思います。ObjectACLを使いましょう。
      • 個人的な感覚ですが、bucketACLはBucketPolicyに置き換えたほうが良いなと思っています。
    • IAM
      • IAMとBucketPolicyの違いはユーザ（クライアント）側に紐付いて権限が与えられるということ
      • どっちで管理した方が楽か。
  • 暗号化キー
    • Amazon S3 が管理するキーによるサーバー側の暗号化 (SSE-S3) S3 Managed Keys
    • AWS Key Management Service に保存されているカスタマーマスターキー (CMK) によるサーバー側の暗号化 (SSE-KMS) AWS KMS Keys
    • お客様が指定したキーによるサーバー側の暗号化 (SSE-C)
  • AWS KMS キーを使用した暗号化で、大容量ファイルを Amazon S3 にアップロードしようとしています。アップロードに失敗する理由は何ですか ?
    • -> kms:Encrypt、kms:ReEncrypt、kms:GenerateDataKey、および kms:DescribeKey に対する許可も持っている必要があります。
    • -> Amazon S3 はマルチパート アップロードを完了する前に、暗号化されたファイル パートからデータを復号化して読み込む必要があるため、このアクセス許可が必要です。
    • キーポリシーと IAM アクセス許可の両方に対して、kms:Decrypt へのアクセス許可が必要
  • サーバー側の暗号化の要求
    • 特定の Amazon S3 バケット内のすべてのオブジェクトのサーバー側の暗号化を要求するには、ポリシーを使用できます。
    • たとえば、SSE-KMS を使用したサーバー側の暗号化を要求する s3:PutObject ヘッダーがリクエストに含まれていない場合、次のバケットポリシーはすべてのユーザーに対し、オブジェクト (x-amz-server-side-encryption) をアップロードするアクセス許可を拒否します。
    • -> 暗号化要件あるのに、暗号化しないオブジェクトがアップロードされるのを防ぐ

Storage Gateway

RDS

  • Amazon RDS リソースの暗号化オプションを有効化すると、AES-256 暗号化アルゴリズムにより以下のデータを暗号化することができます。
    • DB インスタンス
    • 自動バックアップ
    • リードレプリカ
    • スナップショット
    • ログ
  • 暗号化オプションはDB インスタンスの作成時にのみ有効にすることができ、作成後のインスタンスでは有効にすることができません。ただし暗号化されていないスナップショットのコピーは暗号化することが可能です。
  • Amazon RDS の暗号化されたインスタンスのリードレプリカも、同じ AWS リージョンにある場合にマスターインスタンスと同じキーを使用して暗号化されます。マスターとリードレプリカが異なる AWS リージョンにある場合には、その AWS リージョンの暗号化キーを使用して暗号化します。
    • 暗号化するリードレプリカは、両方が同じ AWS リージョンにある場合、ソース DB インスタンスと同じキーで暗号化する必要があります。

Codeシリーズ

  • Use Parameter Store to Securely Access Secrets and Config Data in AWS CodeDeploy

Cloud Formation

  • cfn-signal ヘルパースクリプトは、Amazon EC2 インスタンスが正常に作成または更新されたかどうかを示すシグナルを AWS CloudFormation に送信します。
  • Service Catalog
    • https://www.idnet.co.jp/column/page_056.html
    • CloudFormationで作成したテンプレートを登録しそのテンプレートをユーザに利用させることが出来るサービス
    • Service Catalogの利用に必要なものは以下の3つです。
      • ① IAMユーザ（またはロール、グループ）に割り当てるService Catalogの利用権限
      • ② ③のテンプレートを利用するための権限を割り当てたロール
      • ③ ユーザに利用させるCloudFormationテンプレート

QuickSight

  • QuickSightにはSPICEというインメモリ型の高速データベースが内蔵されています。
  • サポートされているデータソース
    • リレーショナルデータソース
    • CSV/TSV、ELF/CLF、JSON、XLSX
    • GitHubや、JIRA等、SaaS
  • IAMユーザに閲覧権を付与できる
  • エンタープライズエディションなら
    • ADを取り込める
    • データの暗号化

コスト管理ツール

  • AWS のコストと使用状況レポート (CUR)
  • レガシー DBR を使用している場合は、レポートを コストと使用状況レポート に移行することを強くお勧めします。
  • AWS CUR は、最も包括的な情報源を提供します。個々のコストを細かく把握し、詳しく分析できるため、特にエンタープライズ規模に役立ちます。AWS CUR は、専用のクエリや分析ベースのシステムなど、複雑なコスト管理のニーズを持つユーザーに最適です。AWS CUR は、特に償却費を確認する場合、リザーブドインスタンス (RI) の情報源としても最適です。
  • 請求アラートを作成できる
  • RI 使用率レポート
    • RI 使用率レポートは、Amazon EC2、Amazon Redshift、Amazon RDS、Amazon Elasticsearch Service および Amazon ElastiCache リザーブドインスタンス (RI) の使用率、RI による削減額、RI を浪費した額、選択した時間範囲で RI の購入から得られた純削減額を示します。
    • これにより、RI を過剰購入していないか判断できます。

サポート

  • AWS サポートのプラン比較
    • Developer, Business, Enterprise

httpsについて調べたことメモ

技術全般

はじめに

  • HTTPSまわりについて復習したときのメモ

参考

メモ

HTTPSとは

  • HTTPを暗号化
  • 例えると、HTTPは「はがき」で、HTTPSが「封書」のようなもの
  • （参考）ネットワーク通信経路暗号化の意味
    • 盗聴を防ぐ
    • 改ざんを防ぐ
    • なりすましを防ぐ
  • HTTPで行われるウェブ通信に、「SSL/TLS」をくわえて「ウェブで情報を安全にやりとりする仕組み」にしたものが、「HTTPS」
    • SSL は仕組みとしては使われていないけど、「情報を安全にやりとりする」という意味の言葉として使われている
      • 「SSL」は「TLS」の前身となる仕組み
    • TLS は「情報を安全にやりとりする」ために実際に使われている仕組み
    • HTTPS は「ウェブで情報を安全にやりとりすること」を具体的に表現した言葉

SSL通信の仕組みと流れ

  1. SSLサーバー証明書と公開鍵を送る
    • サーバーが HTTPS での接続リクエストを受けると、はじめに SSLサーバー証明書 をクライアント側（ブラウザ）に送ります。
    • SSLサーバー証明書には公開鍵が含まれています。
    • 公開鍵は、サーバー側にある秘密鍵でしか復号できないため、暗号化する前に送っても大丈夫ですね。
  2. SSLサーバー証明書の有効性確認と共通鍵の生成
  3. 共通鍵を公開鍵で暗号化して送る
    • 生成した共通鍵を盗まれないように、公開鍵で暗号化しサーバーに送信します。
      • 共通鍵はクライアント側で作成。公開鍵で暗号化してサーバー側に送る！
    • サーバー側は、送られてきた公開鍵を秘密鍵で復号し、共通鍵を取り出します。これで、サーバーとクライアントの両方が安全に共通鍵を持つことができました。
  4. SSL通信を開始
    • あとは、共通鍵を使って暗号化通信をしていきます。

関連キーワード

  • 認証局
    • この公開鍵は確かに本人のものですよ、と証明する機構
    • どうやって公開鍵の正当性を保証するか
      • 1_管理者が公開鍵を認証局に登録しておく
        • -> CAはデジタル証明書を発行してあげる
      • 2_認証局に登録した鍵によって身分を保証
        • エンドユーザ（ブラウザ）が、使う時に、自分の知るルート証明書と照合して確認
  • オレオレ証明書

AtCoderTagsから、ABCのE問題でよく出題されているカテゴリーを雑に集計してみる

競プロ

はじめに

  • いつかE問題も解けるようになりたいなー
  • -> E問題ってどのカテゴリーの問題がよく出ているんだろう
  • -> AtCoder Tagsという素晴らしいサイトがあったので、雑にスクレイピングして集計してみた

結果（新ABCのみ集計。126-163）

A問題

[('Easy', 35), ('String', 2), ('Searching', 1)]

f:id:noko_htn:20200425171506p:plain

B問題

[('Easy', 23), ('String', 5), ('Searching', 3), ('Mathematics', 3), ('Ad-Hoc', 2), ('Construct', 1), ('Greedy-Methods', 1)]

f:id:noko_htn:20200425171539p:plain

C問題

[('Mathematics', 9), ('Searching', 9), ('Ad-Hoc', 5), ('Easy', 3), ('Construct', 3), ('Greedy-Methods', 3), ('Technique', 2), ('Data-Structure', 2), ('Dynamic-Programming', 1), ('String', 1)]

f:id:noko_htn:20200425171558p:plain

D問題

[('Mathematics', 10), ('Searching', 7), ('Ad-Hoc', 5), ('Graph', 4), ('Data-Structure', 4), ('Dynamic-Programming', 3), ('Technique', 3), ('Construct', 1), ('Greedy-Methods', 1)]

f:id:noko_htn:20200425171628p:plain

E問題

[('Dynamic-Programming', 11), ('Mathematics', 8), ('Searching', 5), ('Data-Structure', 4), ('Graph', 3), ('Construct', 2), ('Greedy-Methods', 2), ('String', 1), ('Technique', 1), ('Ad-Hoc', 1)]

f:id:noko_htn:20200425171651p:plain

F問題

[('Dynamic-Programming', 12), ('Graph', 5), ('Mathematics', 5), ('Data-Structure', 3), ('Geometry', 3), ('Construct', 2), ('Searching', 2), ('String', 2), ('Technique', 2), ('Ad-Hoc', 2)]

f:id:noko_htn:20200425171712p:plain

スクリプト

# !pip install requests
# !pip install beautifulsoup4
import requests
from bs4 import BeautifulSoup
import re
import ast

start_contest = 126
end_contest = 163
problem_num = '_e'
max_tag_list = []
for i in range(start_contest, end_contest+1):
    # http get
    url = 'https://atcoder-tags.herokuapp.com/check/abc' + str(i) + problem_num
    print('url: ' + url)
    response = requests.get(url)

    # parse
    soup = BeautifulSoup(response.text, "html.parser")

    # get the relevant part
    lines = str(soup).splitlines()
    for line in lines:
        if line.find("var dict") >= 0:
            tag_dict_str_raw = line

    r = re.compile( '(%s.*%s)' % ('{','}'))
    tag_dict_str_re = r.search(tag_dict_str_raw)
    tag_dict_str = ''
    if m is not None:
        tag_dict_str = tag_dict_str_re.group(0)

    # str->dict
    tag_dict = ast.literal_eval(tag_dict_str)

    # get max key
    max_tag = max(tag_dict, key=tag_dict.get)
    max_tag_list.append(max_tag)

# aggregate　results
import collections
counter = collections.Counter(max_tag_list)
count = counter.most_common()
print(count)

# visualization
# !pip install matplotlib
import matplotlib.pyplot as plt
%matplotlib inline

x = [x[1] for x in count][:10]
label = [label[0] for label in count][:10]

plt.figure(figsize=(5,5), dpi=100)
plt.pie(x, labels=label, startangle=90, counterclock=False, autopct='%.1f%%', pctdistance=0.75)
plt.axis('equal') 
plt.show()

おわりに

  • DP頑張ります。

機械学習基盤（推論環境）の設計・構築フェーズで考えること

技術全般

はじめに

  • AIな案件で、データサイエンティストによるPoCに目処がつき、機械学習エンジニア？データエンジニア？ソフトウェアエンジニア？により実システムに落とし込んでいくぞ！という段階でやったこと・気を付けるべきことのメモです。
  • モデリングはなんとなく終わっていて、インフラ構築して、APIバックエンド構築して、モデルをデプロイして、テストしていく感じを想定しています。（推論環境にフォーカスしています。）

フェーズの大まかな流れ

フェーズ別のやったこと・気を付けるべきこと

01_PJ独自要件確認

  • 環境について
    • オンプレで作るのかクラウドで作るのか。相乗りするのか新規に作るのか。
    • 既存環境のリソースの余り具合、構築期間（アカウント発行に掛かる期間等）、セキュリティ要件、結局GPUどこで使えるんだ、あたりを考慮して決める。
    • 運用基盤（リリース、監視、バックアップ、改廃）は既存の仕組みを使えるか新規に構築するか。
  • データ連携
    • オンライン処理かバッチ処理か。（連携頻度、サイズも確認）
    • APIで連携するのかファイルで連携するのか。
    • 転移学習どうするのか。（個人情報とかあればデータの保存期間に注意）
  • 役割分担
    • レイヤ（モデル・インフラ・バックエンド・フロントエンド）×フェーズ（設計・構築・運用）　※他ベンダが絡むときは特に
    • 特に、運用ベンダと認識を合わせておく（保守運用費、引継ぎ可能か、モジュールの受け渡し）
    • 費用の分担（開発環境のインフラコスト、ライセンス利用料等）

02_アーキテクチャ検討（サービス選定、ミドルウェア選定）、構築

  • 「（上記の）PJ独自要件」「動作可否」「性能（TAT、スループット）」「ランニングコスト」「運用コスト（デプロイ、監視等）」あたりを考慮して比較検討する。
    • 通常のアプリケーションと比較して、枯れていないパッケージを使いがちなので、きちんと早めの段階で動作確認しておく。（以外と相性とかある。パッケージとAPサーバの相性とか）
    • 通常のアプリケーションと同様だが、「負荷が重そうな処理だけ先行して簡易性能テストをしたが、後から他の処理の方が重かった」はあるあるなので気を付ける。
    • CIに「モデル精度のテスト」も組み込む。前モデルとの比較なり、ベースラインとの比較なり。

03_パラメータチューニング

  • 性能要件を満たす[インスタンスタイプ×台数]の内、最もランニングコストが低い構成を探す
  • インスタンスタイプ
    • 特にCPU使用率、メモリ使用率、GPU使用率、GPUメモリ使用率
      • 例えばAWSだと、CPU負荷とGPU負荷のバランス的にp2系よりg3系など
  • 起動プロセス数
    • 起動プロセス数に比例して確保するGPUメモリ使用率が増えたりするのでちょうどいいところを探す
    • GPUメモリの挙動は注意。プロセスがGPUを利用する際に多めにメモリを使用し、その後少し下がったところで落ち着くから、アプリ起動時にウォームアップさせよう、など。

まとめ

  • 「重い処理に絞って事前性能検証をしたが残りに重いのが、」はよくやりがち。早く全部やってみる。
  • 早く本番の構成、ライブラリバージョンを固めて動作確認する。意外と相性とかあったりする。
  • GPUの挙動をよく見ておく。起動時に一気に確保しにかかったりする。（制御できたりするが。）

おわりに

  • 基本的に通常のシステム構築と同じですが、AIシステム独特な部分もあるので、実務を通してナレッジを貯めていきたいと思います。