血と汗となみだを流す

クラウドエンジニアになるための修業の場

Amazon RDSのリードレプリカ台数について(MySQL)

Amazon RDS Read Replicaとは?

この記事の対象

リードレプリカを作れる台数

  • 1つのmasterから作れるリードレプリカは5台がMAX
  • AWSサポートに問い合わせることにより上限緩和できる「リードレプリカの上限数」とは異なる
    • AWSサポートで上限緩和できるのは「トータルのリードレプリカ数」
    • (ex)
      • master A のリードレプリカ x 4
      • master B のリードレプリカ ← トータル5台なので1台しかレプリカを作れない
        • 緩和後、2台以上作れる
        • が、 1つのmasterから作れるリードレプリカは5台 は緩和されない

リードレプリカのリードレプリカ

  • MySQL5.6以降のバージョンなら、リードレプリカをソースにリードレプリカを作成できる
    • ソースのDBインスタンスMySQLが5.6以上であること
    • 自動バックアップを有効であること
  • リードレプリカのリードレプリカの・・・・は4つ以上作ることはできない
    • (ex)
      • master - ReadReplica1(OK) - ReadReplica2(OK) - ReadReplica3(OK) - ReadReplica4(NG)
  • MySQL および MariaDB リードレプリカ

ElastiCacheノード入れ替えイベントについてのまとめメモ

※以前書いたのも混ざってます

primary/replica同時にノード入れ替え発生

  • 20180731時点
  • 2ノードのレプリケーショングループとしていて、primary/replicaが「同時に」ノード入れ替え対象となった場合
    • メンテナンスウィンドウはレプリケーショングループ単位の指定なので、片方ずつメンテナンスウィンドウを設定することが出来ない
    • 予定期間のメンテナンスウィンドウ時間内にprimary/replica同時にノード入れ替えが発生するように見える
    • が!!primary/replica同時に発生した場合は、どちらかが翌週のメンテナンスウィンドウに延長されるらしい
    • 翌週なので予定期間外にも関わらず実施されるっぽい

ElastiCacheのメンテナンスウィンドウを手動で変更することに発生する現象

  • 20180727時点
  • ノード入れ替えイベントが発生した際に、最初に設定されていたメンテナンスウィンドウの時間を前倒しすると、予定期間より前にノード入れ替えが発生する現象がある
  • 例(マジであった)
    • ノード入れ替えイベント発生!
    • 期間は 2018/07/23(月)00:00〜2018/07/29(日)23:59の、メンテナンスウィンドウ(web 0:00〜1:00)の時間帯に実施!
      • つまり7/29(水)の0:00〜1:00に発生
    • メンテナンスウィンドウを(sun 0:00〜1:00)に変更!
      • 7/29(日)0:00〜1:00に発生するはず・・・!
    • 7/22(日)0:00〜1:00に発生

アプリケーション側のコネクションを張り直す必要がある場合(裏は取れていません。発生した現象です)

  • コネクションが切れなかったため、アプリケーション側でコネクションを張り直す必要がありました。
    • ノードのスケールアップ
    • FailOverを2回する(1回はOK)

Amazon EKSを触ってみる①

概要

  • 安定のDevelopers.IOさんの記事をトレースしながら仕様などを把握する!

やってみる

kubectlのupgrade

  • 昔入れてたのでkubectlをupgrade
  • clientのバージョン確認
$ kubectl version --short --client
  • kubectlのバージョンアップ(mac)
$ brew upgrade kubectl
  • heptio-autenticator-aws
    • 用途や目的がここではよくわからんかった
    • そのうち理解できるかも、、、ってことでスキップ

kubectl確認

  • 以下の「all」オプションがなかった
$ kubectl get all
  • 他の接続確認方法がわからなかったので、pod建てたら確認することとする

Amazon EKSの料金体系(気になったので)

作成した Amazon EKS クラスターごとに、1 時間あたり 0.20 USD の料金が発生します。
Kubernetes の名前空間と IAM セキュリティポリシーを活用すると、
Amazon EKS クラスター 1 つで複数のアプリケーションを実行することができます。

Kubernetes ワーカーノード実行用の AWS リソース (EC2 インスタンス、EBS ボリュームなど) に対して料金が発生します。
実際に使用した分に対してのみ料金が発生します。
最低料金や前払いの義務はありません。

本日のAWSメモ

ElastiCacheのメンテナンスウィンドウで発生する現象

  • 20180727時点
  • ノード入れ替えイベントが発生した際に、最初に設定されていたメンテナンスウィンドウの時間を前倒しすると、予定期間より前にノード入れ替えが発生する現象がある
  • 例(マジであった)
    • ノード入れ替えイベント発生!
    • 期間は 2018/07/23(月)00:00〜2018/07/29(日)23:59の、メンテナンスウィンドウ(web 0:00〜1:00)の時間帯に実施!
      • つまり7/29(水)の0:00〜1:00に発生
    • メンテナンスウィンドウを(sun 0:00〜1:00)に変更!
      • 7/29(日)0:00〜1:00に発生するはず・・・!
    • 7/22(日)0:00〜1:00に発生

IAMポリシー

  • AdministratorAccessと、一部機能にDenyが付いたポリシーを同時にアタッチすると、一部機能が使えない管理者権限が作れる
  • サポートプランの変更、アカウント自体の削除はroot権限しか出来ない

Availability Zoneをまたいだ通信

  • 同じAZに配置されたEC2→RDSの通信のほうが、異なるAZに配置された通信より早い
  • つまり通信の最適化をしたいなら、同じAZに配置したほうが良い

Aurora for MySQL

  • t2ファミリーはmediumまでしかない
  • あとは全部r系

Amazon ECS(EC2 Container Service)のネットワークモードについて

概要

  • Amazon ECSのtask definitionを作るときに選択する「ネットワークモード」について調べた

ネットワークモード

none

  • 起動タイプ: EC2のみ
  • コンテナから外部へアクセスはできない
  • ポートマッピングは無効

bridge/default

  • 起動タイプ: EC2のみ
  • コンテナは仮想ブリッジdocker0を使って通信する
  • コンテナインスタンスの外と通信するときは仮想ブリッジを使ってコンテナインスタンスのNetwork Interfaceを使う
  • そのため、複数コンテナが起動しているとNetwork Interfaceを共有する
  • ポートマッピング有効
  • Windowsで唯一サポートされるモード

host

awsvpc

  • 起動タイプ: EC2/Fargate
  • task definitionにNetwork Interfaceを割り当てる
  • ポートマッピング有効

Developers.ioの記事を読んでやってみる「AWS Cogito + API Gateway」

対象

やってみる

前提

  • 機能を理解するのが目的なので、terraformは使わずにAWSコンソールからポチポチ
  • ローカル環境はMac

Angular SPA でログインし、API Gateway を呼び出す

手順

  • 認可不要の API を定義し、SPAからデータを取得してみる
  • Cognito User Pools を作成し、新しいユーザーを用意する
  • Cognito User Pools から払い出された IDトークンが必要になるよう API Gateway に制限をかける
  • SPA にサインイン機能を追加する
  • SPA から制限付きAPIをコールする

準備

ローカル環境でもSPA(Single Page Application)を検証できるようにする

$ brew install npm
  • angular-http-serverをインストール(グローバルインストールしたら ng new でプロジェクト作れなかったのでグローバルインストールはしなかった)
$ npm install angular-http-server
  • Angular CLIインストール
$ npm install -g @angular/cli
  • Anglura CLIバージョン確認
$ ng -v
  • 存在感がすごい
➜  spa ng -v

    _                      _                 ____ _     ___
   / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
  / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
 / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
/_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
               |___/

Angular CLI: 1.7.4
Node: 9.11.1
OS: darwin x64
Angular:
...
- プロジェクト作成

$ ng new cognitotest

- プロジェクトをbuild

$ cd cognitotest $ ng build

- HTTPサーバ起動

$ cd dist $ angular-http-server

- `http://localhost:8080/` にアクセスして確認
[f:id:Anorlondo448:20180425062759p:plain]

### TypeScriptインストール
- インストール

$ npm install -g typescript



## 認可不要のAPIを使ってDynamoDBのデータを取得する
- [Amazon DynamoDB のデータを API Gateway と Angular( D3.js ) でサーバーレス可視化する](https://dev.classmethod.jp/server-side/serverless/visualize-dynamodb-serverless/)を見ながら作る
### Angular + D3.js でデータ可視化の準備をする
- tsファイルを作成

$ cd cognitotest/dist $ touch data.ts $ touch vote-bar-chart.ts

- 実装(ソースコピペ)
- 

Tech-on MeetUp#01「開発現場に効くサーバーレス」に参加しました!

概要

このイベントでGETしてきたもの

  • lambdaのBlueprintsに「slack-echo-command-python」というのがある
  • ServerlessFramework
    • サーバレス関連のリソースを良い感じに管理してくれる
  • ローカルでサーバレスの検証をするため、lambdaのコードをWebサーバでも動くようにラップして可搬性を高める
  • 24/365という無敵のサービス

以下、概要メモ書き

Tech-onとは

  • ホンモノのナレッジは人と人との緩いつながりの中にこそある
  • テーマを特定の技術に限定しない
  • 開発の現場にいる技術者が登壇
  • slideshareで公開されるのでバシャバシャ撮影しなくてよし

NG

  • 製品紹介や広告は原則禁止

資料

明日から始めるちょい足しλ

  • 中丸 良@SUPINFさん
  • 開発現場に効くサーバレス
    • 改善策を探していたら、結果的に
  • AWS Lambdaは想像以上に難しい
  • メンテナンスし続けるコスト、まったくもって無視できない
  • 研究、PoC期間をちゃんと設けて小さめにスタート

社内の情報共有に

  • どこにどんな情報があるか
  • labmdaのBlueprintsに「slack-echo-command-python」というのがある

秘密情報の共有

  • デフォルトのBlueprintsになかったらOSSを探そう

Githubの歩き方

  • 調査段階でawesome-serverlessなどで探すのは有用

lambda@edge

  • AWSのCLoudFront上で動くlambda

運用プロセスも改善したい

  • 開発プロセス全般のソリューションとして使えるサーバレスがawesome-xxxにある
  • 安易に自作しようとしない
  • 新技術を研究する時間は別途とり、かつ成果は義務付けない

おすすめ

  • ks888/LambStatus
  • lambci/lambci
  • prismagraphql/chromeless
  • grycap/scar
    • lambdaでdocker動かす

運用のためのヒント

  • CI/CDパイプラインを組む
  • CloudWatchで監視

社内からの声

  • 「それサーバレスにした理由は?」を確認しよう

ローカル環境で気軽にはじめるサーバーレス

  • TatchNicolasさん

資料

サーバレスを始める時の悩み

  • 各種申請

身近で怒った悲劇

  • 無限ループによる高級請求
  • 定期実行の単位違い
  • ローカルで手軽に試したい・・・

ローカルで動かすには

擬似的なクラウド環境

  • AWS
    • SAM CLI
    • DynamoDB local
  • OSS

    • Serverless Framework
    • localstack
  • 擬似的なクラウド

    • dockerで起動
    • インターネットがないところでもサーバレスが検証可能

可搬性を高めるパターン

  • 任意のWebサーバで受けられるようにする
  • lambdaのコードをWebサーバでも動くようにラップして可搬性を高める
  • ラップする
  • 使えるツール、フレームワーク
    • awsgi
    • Zappa
  • Faas以外にも移動できる
    • ベンダーロックイン回避

QA

  • フレームワークにイベントを擬似的に発行できる機能がある
    • 連続してイベント発行は厳しい

KDDIとCI/CDの歩み

  • 廣田 翼@KDDIさん

概要

  • CI/CDをどのように浸透させて
  • どのような課題があって
  • どのように解決したのか

CI/CI概論

  • Continuous Integration
  • Continuous Delivery

CI/CDの効果

CI

  • 常に出荷可能な品質を維持できる

CD

  • 常にサービス提供/更新できる状態を保てる

導入

  • プロジェクト初期にCI/CD導入を目指す
  • プロジェクト/プロダクトの特性に応じたCI/CDを作っている

課題/対応

  • デプロイ作業が属人化
    • GithubEnterprise + Jenkins
  • CI/CDの設定自体もコード化
    • Jenkinsの設定をコード化
  • CI/CDに詳しい人材の不足
    • 詳しい人材を流動的にした

普及のポイント

  • 成功事例を作る
  • 理解している人材をプロジェクトに参加させる

QA

  • 県境毎にbranchがあり、そこにpushされたらデプロイが走る

StepFunctionsを一撃でデプロイする 〜 ServerlessFrameworkを用いたパッケージング 〜

  • 若松 剛志@アイレットさん

概要

  • サーバ管理サーバのサーバ管理はしたくない

ツール

  • Lambda
  • StepFunctions
  • ServerlessFramework
  • CodeDeploy

内容

とりあえずlambdaでやってみた

  • 制限が厳しい
  • 5分制限で落ちる

StepFunctionsがあるじゃん

  • 複雑に・・・
  • 1lambda1Functionになった
  • コケたポイントがわかる
  • リトライなどの制御が楽
  • JSONが辛い

ServerlessFramework

  • Serverlessに特化した構成管理ツール
  • YAMLで管理
  • 設定/コードが一箇所になった
  • JSONYAML変換が辛い
  • SF自体の改善点が多い
    • Role名で指定できないなど

監視

  • 24/365
  • lambdaのエラーハンドリングが難しい
  • エラーが起きる想定で対応するということで落ち着いた

結果

  • サーバの管理から開放された
  • 運用自体はなくならない
  • 構成管理が見える化した

課題

  • CI/CD
    • deployの均一化