読者です 読者をやめる 読者になる 読者になる

ミッションたぶんPossible

どこにでもいるシステムエンジニアのなんでもない日記です。たぶん。

4/26(水)、「GitHubとクラスメソッドの勉強会〜GitHub x AWSの最新DevOps事情〜」参加レポート

f:id:takigawa401:20170426210316j:plain

はじめに

 東京丸の内:株式会社IDOMさんで開催されたGitHub社・クラスメソッド社の合同開催勉強会「GitHubとクラスメソッドの勉強会〜GitHub x AWSの最新DevOps事情〜」に参加してきました。以下、聴講メモ。


classmethod.connpass.com


メモ

開催概要・諸注意
  • How we ship GitHub
    • スピーカー
      • GitHub池 田タカフミさん(@ikeike443)
        • GitHubは入社するとGitHubのアカウント名のままメールアドレスが作られる
        • セキュリティ強固だからクレジットカード番号とかウェルカム
    • 最近のGitHub
      • 企業向けもガンガン
      • Developer 個人
      • Team チーム
      • Business ビジネス用途
      • GitHub Enterpriseという呼び方はだんだん無くなっていく、Businessプランに集約
    • DevOps
      • 色んな人が色んな意味で使ってる
        • インフラ効率化
        • リリース自動化
        • ただの何かのツール
      • 大事なのは
        • 価値を無駄なく遅滞なく届けること!
    • 近年起きていること
      • アジャイル
        • 三角形はさかさまに
          • スコープがFix、リソースとタイムを動かす
          • →リソースと時間がFix、スコープを動かす
          • →世の中の変化の方が早いので
        • イテレーティブに開発しましょうね
      • コラボレーションがやりやすく
        • 中央集権型→分散型へ
      • CI
        • 必須のプラクティス
      • Continuous deliveryy
        • 今のDevOpsブームが目指しているところ
      • Continuous deployment
        • 常に本番にデプロイされている状態
        • ここまで行くべき
          • ネットフリックス
          • GitHubでは?
            • 数十回デプロイ/日
            • GitHubberは世界中に散らばっている
              • 60%はリモート
              • 日本は11人
                • 実際にはもうちょっといる
              • 米国が明らかに多い
                • 米国各地に散らばっている
              • 地理的にもタイムゾーン的にもバラバラ
            • どうやっているか?
              • GitHub Flow
                • Guide.github.com
                • Masterを
                • 常にデプロイ可能な状態に保つ
                  • 本番とイコールに
                • 必ずブランチを作って開発
                  • 生存サイクルを短く
                • 溜め込まずすぐPull Requestを作り、フィードバックをもらう
                  • Hubotが大活躍
                • Pull Requestブランチを各環境にリリース
                • 問題ないものだけMasterにリリース(マージ)
                  1. もし現在のMASTERブランチの内容がPull Requestブランチに無い場合は、まずMSTER→Pull Requestにマージ
                  2. もう一度テスト
                  3. Masterにコミット
              • Hubot(ChatOps)
                • ディスカッション上で重要な役割
                • OSSチャットボットの仕組み
                  • GitHubで一番働いてるのは人間じゃない!
                • チャット上で様々なオペレーションを行う
                • なぜチャットか
                  • Shared Console
                  • 誰がやっても同じ結果が出る
                  • 他人がやってる様子をチャット上で見て学べる
                  • いつでもどこでもリモートワーク
                    • デプロイだけならスマホでもできる
                      • さすがにコード書くのにはPCが必要
                  • Pull Requestリリース時に、自分がどこにリリース可能か、教えてくれる
                  • Deplyment API
                    • チャットコマンド上で手軽にリリースできる
                  • 「queue for github
                    • プロダクションへのデプロイ待ち状況をHubotが教えてくれる
                      • 待ちが発生している間は他の人がデプロイはできない
                  • Deployment confidence
                    • デプロイしたものが本番環境でどのように動作しているかを確認できる
                  • 様々な形での支援
                    • 自動でISSUEを立ててくれる
                    • etc
                    • チャットやグラフで確認可能
            • 様々なことを全てChatで
              • CIのセットアップ
              • 営業的な見積
              • メンバーの居場所通知
              • Google Map確認
              • 画像(ランダム)
              • GIF画像
              • 近くにいる人
              • メンバーのプロフィールをhubotが紹介
            • 様々なツールを活用
              • GitHub
              • Hubot
              • Slack
              • Janky
              • Heaven
              • Heroku
              • gPanel
              • sentinel
              • etc...
  • まとめ
    • 市場のニーズはすごいスピードで変わっていってる
    • DevOpsは必須
      • さらにその先へ
    • リモートで非同期に
    • ChatOpsは企業をグローバルかつフレキシブルなスタイルに
    • AIが絡んでくる?
DevOpsとAWSサービス
    • スピーカー
      • 千葉 淳さん
        • クラスメソッドAWS事業部
        • 自動化大好き
        • ゼルダ毎日やってる
    • 会場アンケート(挙手)
      • アプリやってる人
        • 半分くらい
      • インフラやってる人
        • 半分くらい
      • AWSやってる人
        • けっこう
    • DevOpsとは?
      • 開発者と運用者が協力した開発手法(Wikipedia)
      • 安全に素早くリリースするための仕組み
        • 属人化の排除
          • 「あの人なら知ってる」をなくす
          • 手作業をなくす
          • デリバリの自動化
            • ビルドからデプロイまで
          • コードで管理
        • 開発の効率化
          • チームコラボレーション
            • GitHub
            • Backlog
            • Slack
            • Atlassian
          • 小さくたくさんリリース
        • 安全なリリース
          • デプロイ自動化
          • フローの整理
            • 承認とか
        • 柔軟性
          • バージョンアップ
          • セキュリティパッチ
          • スケールアップ・スケールダウン
        • モニタリング
    • DevOpsの目的
      • ビジネスに使う時間を増やす
        • デプロイ:月1回→毎日10回
        • 運用者:10人→3人
      • -
    • CIとは?
      • ビルド・テストの自動化
      • 小さくたくさん回す
    • 継続的デリバリー(CD)とは?
      • CIにデプロイまで含む
      • 統合テスト
    • AWSサービス紹介
      • CodeCommit
        • バージョン管理
        • コードビュア
        • SSH(鍵登録) or HTTPS(ID/PW)で接続可能
        • コミット一覧
        • コミット履歴
      • CodeBuild
        • フルマネージドなビルド環境
        • インフラ管理不要
        • サーバスペックを選択可能
        • 数クリックでビルド環境を作成
        • コンテナを利用したクリーンな環境でビルド
          • コンテナを指定可能
        • ビルド環境のスペックを指定
        • ビルド自動化
        • 実行結果・ログをコンソールで確認可能
        • 環境変数の設定が可能
      • CodeDeploy
        • フルマネージドなデプロイサービス
        • CodeDeployエージェント経由でコマンドを実行
        • 数1000台の環境にスケール可能
        • ローリングアップデート Blue/Greenデプロイ
        • 自動化
        • 画面で確認可能
        • デプロイとプロビジョニングを混ぜない!
          • デプロイ:アプリケーション
          • プロビジョニング:OS・ミドルウェアの設定
          • デプロイとプロビジョニングはライフサイクルが異なる
            • 同時に行おうとすると柔軟性を損なう
      • CodePipeline
        • ビルド・テスト・デプロイ・承認などのワークフロー管理
      • CodeStart
        • ここまでのCodeXXXを使ってCI/CD環境を一発で作成できる
      • マイクロサービス
      • 他色々
        • 時間がないので猛ダッシュで
      • サービスをどう選ぶ?
        • 時間がないので後で見てね♪
    • 実装例
      • 例1:CI/CD EC2でBlue/Greenデプロイ
      • 例2:CI/CD ECS
    • まとめ
      • 安全に早くたくさんリリース
      • ユーザーに提供する価値を増やす
      • リリースフローの見える化、自動化
      • モニタリング可能に
      • 開発者・運用者・経営者、三方良しに!


GitHub EnterpriseとAWSを組み合わせたCDP
    • スピーカー
      • 中山幸治(github:knakkayama)
        • オンプレサーバの運用3年
        • AWS歴1年
    • 注意事項
      • 現時点の情報なのでアップデート情報は逐次追ってね
      • Ops寄りな内容多め
    • AWSを使う上での基本姿勢
      • マネージドサービスの利用を検討すること
        • 安定性
        • 他サービスとの連携
        • 運用負荷の低減
        • 自分たちで極力作らない
      • 標準サービスでは要件に会わない場合に自分たちで作る
      • 会社が投資すべきビジネスロジックに集中して取り組む
    • GHEを使う上での基本姿勢
      • GHE自身の設定はいじらない
      • GHEのアップデートで/data/user/以外すべて上書きされるため
      • GitHubが提供してくれる標準機能を利用する
        • 運用負荷を低減した状態でGHEを活用する
  • -
    • Cloud Design Patternの紹介
      • GHEをインターネットに公開したくない
        • セキュリティ上要件的に社外にソースコードを置きたくない
        • プライベートリポジトリをPublicにしてしまった
        • アクセスキーをコミットに含めてしまった
        • 社内LDAPで管理したい
  • ここから先は情報量が多すぎて書ききれないので後日公開資料に任せた!


感想

 とりあえず「GitHubすげえな!」と。チャットってあんなに活用できるもんなんですね。正直ビックリしました。
 同様にhubot凄い。オレの友人に頻繁に承認欲求を満たすために褒めることを要求してくるメンドクサイ奴がいるんですが、そいつのメンタルも管理してくれねーかな。(冗談ですよ、ジョーダン)


 個人的にはお二人目の千葉さんの発表はかなり参考になりました。ちょうどAWS使い始めたばかりだというのもあり、サービス概要を把握してなかった、というのもありますが、今すぐ活用できそうなサービスがあったのも個人的には嬉しかったです。早速明日試してみようかn……いや、明日はダメだ、見積資料作らないとマズイ。


 逆に三人目の中山さんのお話は、そもそも情報量が多かったことと、かなりディープな内容だったこともあって、AWSGitHub Enterpriseも初心者なオレはあっという間に振り落とされました(笑)。最初の事例くらいまでは理解できたんですけどねぇ、GitHub Enterpriseってそんなに色々やんないと使いにくいモンなのかな? 全然使い込みが足らないオレには、その辺がいまいちピンと来なかったです。でもまぁ実際にニーズがあってお客さんがあっての事例でしょうから、必要なんだろうなぁ。



 それはそれとして、クラメソさんの勉強会って、だいぶ久々(数年ぶり?)に参加しました。Adobe Flexとかの頃にはよく参加させて頂いたんですけど。オレ自身、遅まきながらここ最近になってAWSを触り始めたので、また積極的に参加したいですね。


f:id:takigawa401:20170426210337j:plain

4/18(火)、AWS Black Belt Online Seminar サーバレスによるアーキテクチャパターンのご紹介 受講レポート

はじめに

 Amazonが配信している「AWS Black Belt Online Seminar サーバレスによるアーキテクチャパターンのご紹介」を受講しました。以下受講メモ。


メモ

サーバレスによるアーキテクチャパターン

  • AWS Lambdaを中心に
  • ベストプラクティス的なもの
What is Serverless?
  • おさらい程度
  • ユーザーが管理しなければいけないサーバがなくなる
  • AWSのサーバレスの場合
    • シンプルで使いやすい
    • プロビジョニングをしない(できない)
    • 処理実行分に対して課金が発生、アイドルタイムに支払いが発生しない
    • スケーリングは使用率に合わせて自動で行われる
    • 高可用性・組込済み(既にプラットフォーム側で行われている)
    • You don't do that, we do that.
AWSのComputeサービス
スケールの単位 抽象化
EC2 インスタンス ハードウェア
ECS アプリケーション OS
Lambda ファンクション ランタイム
サーバレスなアプリケーションモデル
    1. イベントソース(発生源)における状態変化
    2. ファンクション呼出
    • Java
    • C#
    • Node
    • Python
    • カスタムライブラリも利用可能
    1. サービス呼出
    • DynamoDB
  • -
イベントソース
  • いっぱい
    • S3
    • DynnamoDB
    • Kiness
  • どんどん増え続けている
AWSのサーバレスファリング
  • Lambda≠サーバレス
  • Lambdaが中心になるのはたしか
アーキテクチャパターン
ベストプラクティス
  • The Twelve-Factor App
    • モダンなWebアプリ開発のための方法論
    • 元はHerokuエンジニアが公開
      • コードベース
        • バージョン管理された1つのコードベースと複数のデプロイ
      • 依存関係
        • 明示的に宣言して分離する
        • 暗黙的に依存しない
      • 設定
      • バックエンドサービス
        • アプリケーションがネットワーク越しで利用するようなサービスは全て外部サービスとして扱う
      • ビルド・リリース・ラン
        • 3つのステージを厳密に分離する
      • プロセス
        • ステートレスなプロセスとして実行
      • ポートバインディング
        • アプリ自体がリクエストを待ち受けた方がよい
      • 並行性
      • 廃棄容易性
        • 高速な起動と簡単な廃棄
      • 開発/本番一致
        • 各環境をできるだけ一致させた状態を保つ
      • ログ
        • ログ管理をアプリ自身で行わない
      • 管理プロセス
        • 管理タスクを1回限りの実行プロセスとする
その他の(Lambda特有の)ベストプラクティス
  • メモリ設定
    • メモリを増やすとCPUも倍になる
    • Lambdaはメモリ使用量と処理時間で課金、メモリを増やすとパフォーマンスも向上する
    • 段階的に試して最適化を目指すのが吉
  • VPCは必須ではない
    • 必要でない限り使用しない
    • 使うのはVPC内のリソースにどうしてもアクセスする必要がある時だけ
    • パフォーマンス劣化の原因になる
    • VPC内のリソースとの通信が必要な時は非同期にする
  • Design for failure
    • リトライ
    • Dead Letter Queueの活用(非同期の場合)
  • 冪等性はコードで確保する必要あり
    • Lambdaで保証しているのは最低1回実行すること
    • 場合によっては2回以上実行していることも
  • コールドスタート
    • 安定的なトラフィックが発生している場合、コールドスタートの発生頻度は低い
    • コールドスタートは発生するものと思った方がよい
      • 遅延が一切許容できないのであれば使用しない方がよい
  • ローカル実行について
    • Lambdaで使われているAMIは公開されている
    • ファンクションんと言ってもただのプログラム
    • Contextとイベントを再現する必要がある
      • 単なるJSONオブジェクト
コールドスタートを速くする
  • Lambdaファンっくしょんに対してPingする
    • 定期的にアクセスしてコンテナ破棄を防ぐ
  • コンピューティングリソースうを増やす
    • CPUも早くなるので初期化処理も早くなる
  • ランタイムを変える
    • Java(JVM)は起動が遅い
      • 一回起動しちゃうとJavaの方が早い
  • VPCを使わない
  • パッケージサイズを小さくする
    • サイズが大きくなると起動時間も長くなる
    • 不要なコードは減らす
    • 依存関係を減らす
    • Javaは肥大しがち
  • 初期化処理をハンドラ外に書くとコールドスタートが遅くなるので、遅延ロードを行う
ローカル実行
  • テストドライバ
Q&A
  • 後日ブログで
告知

感想

 AWS Lambdaは今まさに仕事で使っているサービスで、オレにとって実質最初に触ったAWSサービスと言えるんですが、とっても大好きです。こういう要らんこと気にせずに、やりたいことに集中できて、パズルみたいに組み合わせて作れるのは非常に楽しいですね。今回のオンラインセミナーでは、オレが思ってた以上にLambdaの活用パターンがあることが知れて、とても参考になりました。今後Lambdaと連携できるサービスも増えるようですので、今後とも活用していきたいです。

4/12(水)、AWS Black Belt Online Seminar Amazon VPC 受講レポート

はじめに

 Amazonが配信している「AWS Black Belt Online Seminar Amazon VPC」を受講しました。以下受講メモ。


メモ

Virtual Private Cloud

Amazon VPCとは
  • データセンタ・ラック・ネットワーク機器
    • 様々なステップが必要
      • 時間(=コスト)がかかる。早くても数か月
  • クラウドで仮想ネットワークを構築(必要な機能を抽象化、サービスとしてあらかじめ用意されている)
    • 組み合わせてすぐ利用可能
  • クラウドに対する悩み・不安
    • VPCで解決可能
    • AWS上にプライベートネットワーク空間を構築
    • 論理的なネットワーク分離が可能
    • ネットワーク環境のコントロールが可能
    • 複数のコネクティビティオプション
VPCコンポーネント
  • 様々なコンポーネントを用意
    • VPCウィザードで数画面で作成可能
      • 作成過程をウォークスルーで(VPCウィザードを用いずに)説明
        1. アドレスレンジの選択
        2. アベイラビリティゾーンの設定
        3. インターネットへの接続を設定
        4. VPCのIN/OUTトラフィックを許可
      • セットアップの補足
        • サブネット内のDHCP
        • Amazon DNSサーバ
          • DNS機能の有効化とホストへのDNS名割り当て
            • Enable DNS resolution
            • Enable DNS hostname
          • -
      • IPv6の対応
        • IPv4/IPv6デュアルスタックで構築可能
      • VPCにおけるIPv4IPv6の特徴と制限
        • IPv4:デフォルトで適用
        • IPv6:自動適用ではなく任意
オンプレミスとのハイブリッド構成
  • VPN接続
    • 安価なベストエフォート
    • 海鮮も利用可能
  • 専用線(Direct Connnecct)
    • 準備期間が必要
    • よりセキュアに接続できる
  • VPN専用線の並行運用も可能
  • Transit VPC(海外拠点と国内企業をつなぐ)
    • CloudFormationテンプレートとして提供
VPCの設計
  • 使用するAWSサービスがVPCの内外どちらからアクセスするかを確認する
  • NATゲートウェイ
  • VPCを分割するケース
    • アプリケーション
    • 監査スコープ
    • リスクレベル
    • 本番/検証/開発フェーズ
    • 部署
    • 共通サービスの切り出し
    • VPCピアリング(VPCピア接続)
VPCの実装
VPCの運用
  • VPC Flow Logs
  • VPCのリミット関連
    • 超える場合には制限解除申請
まとめ

感想

 メモの少なさからお察しいただけるかと思いますが、途中で振り落とされました。ネットワークの知識が十分でないと、いくら使い方やサービスを聞いてもわかりませんね。猛省。
 それはそれとして、その拙い前提知識でも、Amazon VPCの使いやすさは十分伝わりました。あんなめんどくさい(分からない)ものを、簡単な手順で構築できちゃうのは凄いなぁ。
今回の受講内容で引っ掛かったキーワードを調べ直して、また資料と動画アーカイブに再チャレンジしたいと思います。

4/11(火) AWS Black Belt Online Seminar 初心者向けクラウドコンピューティングはじめの一歩 受講レポート

はじめに

 Amazonが配信している「AWS Black Belt Online Seminar 初心者向けクラウドコンピューティングはじめの一歩」を受講しました。以下受講メモ。

メモ

初心者向けクラウドコンピューティング
  • 初心者向け、新卒向け
クラウドとは
  • 形のないもの
  • 実体は分からないけど使いたいサービスが使い時に使用できる
  • 必要な時に、必要なだけ、低価格で利用
  • 既存インフラ
    • 初期投資が発生
    • 余剰・不足のリスク
    • 固定費
  • クラウド
    • 初期投資が不要
    • 必要な分だけ利用
    • 変動費
  • クラウドの利点
    • 余剰リソースをさけることができる
    • リソース不足による機会損失を避けることができる
  • クラウドの特徴
    • セルフサービス
    • 迅速展開インフラ
    • 低額な利用価格
    • 実際の使用分のみ支払い
    • 初期投資が不要
    • スケールアップ・ダウンが容易
    • ビジネススピードの改善
アマゾンウェブサービスのなりたち
WAWSグローバルインフラストラクチャ
AWSサービス群と活用例
  • AWSサービス群:90以上
    • 顧客要望から生まれた
  • AWSは最も汎用性の高いクラウドの一つ
    • 迅速にクラウド移行を可能にする
    • 様々なOSS / 商用プロダクトを活用できる
      • 1500のパートナー / 3500のソフトウェア
  • 主だったサービス
  • 様々なサービスを組み合わせてシステムを構築できる
  • Serverless Architecture
はじめの一歩
  • アカウントを作ろう
    • インターネット接続可能PC
    • 携帯電話
    • クレジットカード
  • チュートリアル
  • 習うより慣れろ
  • 失敗したら消せばいい
  • 無料利用枠でお試し
  • AWS Trusted Adviser
    • コスト最適化、セキュリティ、耐障害性、性能をチェックし推奨事項をお知らせするサービス
  • AWS知識習得方法
    • 無料オンラインセミナー
    • 無料ドキュメント
    • 有料トレーニング
  • AWS認定資格

感想

 本当に初心者向けなので、「AWSの理解を深める」という点だけ見れば、オレがこのオンラインセミナーを受講する必要は無かったでしょうね。でも、「どうやって初心者に向けてクラウドAWSを説明するか?」という観点では参考になりました。
 内容はとても分かり易いので、セミナー冒頭にもあったように初心者や新卒社員が学ぶには適した内容だと思います。
 このセミナーではスライドのみを画面に映すので発表者(講師)の顔は見えないんですが、それでも声の調子などで相当緊張している様子がうかがえました。あまり発表経験がない方だったのかもしれませんね。

4/05(水)、AWS Black Belt Online Seminar Amazon EC2 受講レポート

はじめに

 Amazonが配信している「AWS Black Belt Online Seminar Amazon EC2」を受講しました。
 今の会社ではAWSの知識が必須なので、それまでレガシーなシステムしか触ってこなかったオレは突貫工事でAWSに関する知識を詰め込んでいってるんですけど、意外と社外勉強会の開催がないorタイミングが合わないこともあり、今後積極的にAmazon主催のオンラインセミナーを活用することになりそうです。


 以下、受講時に取ったメモ。

メモ

EC2の基本
  • EC2
    • どこかのリージョンのどこかのアベイラビリティゾーンで起動
      • インスタンス
        • 仮想コンピューティング
        • 1時間ごと
      • 既存のOS/アプリ/ミドルウェアが利用可能
      • APIでインフラの自動化が可能
        • どのリージョンで起動するか、なども指定できる
  • Amazon VPC(仮想ネットワーク)によるハイブリッド構想
インスタンスタイプ
  • 最大1228vCPU 1952GiBメモリ
      • 小規模向け
      • コア性能重視
      • バランスタイプ
      • メモリ重視
    • 新しいインスタンスタイプを年々追加
  • AMIの分類
    • 32bit/64bit
    • 準仮想化(PV)/完全仮想化(HMV)
    • ブートストレージ
  • インスタンスとHOstの違い
    • アフィニティ:同じところで起動し続ける
ストレージ
  • EC2インスタンスストア
    • ホストコンピューターに内蔵されたディスク
    • EC2を停止→起動するとクリアされる
    • I/Oは早い
  • Amazon Elastic Block store
    • データ永続性
    • 追加利用料金が発生
  • インスタンスストア
  • EBS
    • EC2にアタッチされるストレージ
    • EC2から独立
    • 他のEC2に付け替え可能
    • ネットワーク越しにアタッチ
      • EBS専用回線(ストレージエリアネットワーク)を用意することも可能
ネットワークとセキュリティ
  • 責任共有モデル
    • クラウドの中のセキュリティ:AWS
    • 搭載するアプリ:ユーザー
  • Key Pair
    • 鍵認証でログイン
    • AWS:公開鍵、ユーザー側:秘密鍵でアクセ巣
  • セキュリティグループ
    • アクセスルールをひとまとめにしたグループ
  • AWS上でのIPの種類
    • Elastic IP
      • 明示的にIPを割り当てる
      • 固定IPアドレスが必要な場合のみ(単にアドレスが必要な場合はPublicIPで十分)
      • EIPをインスタンスにアタッチしてない場合は利用料金が発生(有限資産なので)
    • Public ID
      • ランダムに割り当てられる
    • Private IP
      • 必ず割り当てられるIP

  • Elasticc Network Interface(ENI)
    • VPC上で実現する仮想ネットワークインターフェース

  • 拡張ネットワーキング(Enhanced Networking)
    • ネットワークI/Oが必要な場合に活用するサービス
    • スイッチを通さず直接NICにアクセスできる
  • Placemnet Group
    • node間通信が大量発生する場合に有効
運用・監視
  • Cloud Watch
    • AWS各種サービスをモニタリングするためのサービス
      • メトリクス監視
      • メトリクスに対するアラームの作成
      • ログ監視
  • Auto recovery
  • EC2のSLA
    • 可用性:99.95%
    • それに満たない場合には金返してくれるらしい
料金
  • ECC2使用状況レポート
  • Trusted Adviseor
    • ビジネスサポート以上のユーザーのみ
    • 概算見積ツールも
    • AWS無料枠
      • t2.micro 720時間

感想

 EC2はたぶんAWSの中で一番有名かつ一般的なサービスだと思うんですが、実はオレはまだちゃんと使用したことがありません(略式には無いこともない)。今回のオンラインセミナーでは、ハンズオンと違い手を動かすようなことはないので、あくまでEC2というサービスの紹介にとどまる内容なんですが、それでも網羅的に提供サービスを把握できたのはありがたいです。要は既存のレンタルサーバっぽいものだということなので、そういう意味ではこれまでの開発経験が最も活かせるところでもあるとは思っています。まずは無料枠で触ってみるところからかな。
 途中音声トラブルがあってオンラインセミナーが一時中断したんですが、オレが受講したネットワーク環境は妙にネット接続が悪いことがあるので、こちらとあちら、どちらに問題があるのか分からずちょっと焦りました。まぁこういうのはオンラインセミナーならではのトラブルですね。

AWS API GatewayでPOSTリクエストの配列を扱えるようにする

 ここ最近仕事でずっと悩んでたのが、昨晩やっと解決したので、備忘録的にメモメモ。


 クライアントからAWS API Gatewayを経由して AWS Lambdaで処理を行うAPIを開発しているんですが、LambdaはJSONデータしか扱えません。一方クライアントからは通常のHTTPS POSTでリクエストが送信されます。この場合、API Gatewayの統合リクエストにあるマッピングテンプレートでJSONデータに変換してあげる必要があります。このマッピングテンプレートは「Velocityテンプレート言語(VTL)」で記述するのですが、これがイマイチ情報が少なくて書き方が分からない!



f:id:takigawa401:20170407103429j:plain
1. API Gatewayで作成したAPIから「リソース」を選択
2. 「メソッド(「GET」とか「POST」とか。今回は「POST」)」を選択
3. 「統合リクエスト」をクリック

f:id:takigawa401:20170407103436j:plain
4. 「本文マッピングテンプレート」をクリック
5. 「マッピングテンプレートの追加」をクリックして「Content-Type」に「application/x-www-form-urlencoded」を追加

f:id:takigawa401:20170407103444j:plain
6. 追加した「Content-Type」をクリックしてマッピングテンプレートを記述

  • key1[]=value1
  • key1[]=value2
  • key2=value3
  • key3=value4
  • key4[]=value5
  • key4[]=value6
  • key4[]=value7

こういうデータが

key1=value1&key1=value2&key2=value3&key3=value4&key4=value5&key4=value6&key4[]=value7

こういう風にAPI Gatewayにやってくるのを

{
"key1" : ["value1", "value2"],
"key2" : "value3",
"key3" : "value4",
"key4" : ["value5", "value6", "value7"]
}

こう変換したいんですね。
 POSTリクエストをJSONに変換するサンプルはネットでも割と簡単に見つかるんですが、配列まで扱ったサンプルはまず見つからないんですよね。配列を適切に変換しないとこんな風になっちゃいます。

{
"key1[]" : "value2",
"key2" : "value3",
"key3" : "value4",
"key4[]" : "value7"
}

 配列のkeyに「[]」が混入してしまう他、同じkeyだと後勝ちでデータ上書きされるので、配列の中で一番最後に入っている値しか残らない。ふぁっく!




 で、結論から言うと以下のようになりました。

{
    "headers" : {
#foreach( $key in $input.params().header.keySet() )
        "$key" : "$input.params().header.get($key)"#if( $foreach.hasNext ),#end
#end
    },
    "queryParameters" : {
#set( $tmpstr = $input.path('$') )
#set( $arraykeyvalue = {} )

#foreach( $keyandvaluestr in $tmpstr.split( '&' ) )
  #set( $keyandvaluearray = $keyandvaluestr.split( '=' ) )

  #if( $keyandvaluearray[0].indexOf('[]') > 0)
    #set($arraykey = $keyandvaluearray[0].substring(0, $keyandvaluearray[0].indexOf('[]') ))
    #set($arrayvalue = [])
    #if($arraykeyvalue.containsKey($arraykey))
      #set($arrayvalue = $arraykeyvalue.get($arraykey))
    #end
    #set($dev_null = $arrayvalue.add($keyandvaluearray[1]))
    #set($dev_null = $arraykeyvalue.put($arraykey, $keyandvaluearray[1]) )
  #elseif( $keyandvaluearray[0].indexOf('%5B%5D') > 0)
    #set($arraykey = $keyandvaluearray[0].substring(0, $keyandvaluearray[0].indexOf('%5B%5D') ))
    #set($arrayvalue = [])
    #if($arraykeyvalue.containsKey($arraykey))
      #set($arrayvalue = $arraykeyvalue.get($arraykey))
    #end
    #set($dev_null = $arrayvalue.add($keyandvaluearray[1]))
    #set($dev_null = $arraykeyvalue.put($arraykey, $keyandvaluearray[1]) )
  #else
        "$keyandvaluearray[0]" : "$keyandvaluearray[1]",
  #end
#end
#foreach( $key in $arraykeyvalue.keySet())
        "$key" : "$arraykeyvalue.get($key)"#if($foreach.hasNext()),#end
#end
    },
    "stage" : "$context.stage",
    "sourceIp" : "$context.identity.sourceIp",
    "userAgent" : "$context.identity.userAgent"
}


 個人的なキーポイントはこれ!

#set( $arraykeyvalue = {} )

 VTLでHashMapを宣言するには「{}」を指定します。(変数名がいいかげんなのは無視してください。) これがVelocityの公式サイトにもAWSの公式サイトにも書いてなくて、散々探した挙句、海外の掲示板で見つけました。たったこれだけのことに2日も使ってしまうとは……。


 VTLは割とJavaのメソッドがそのまま使えるので、後はそれほど苦労せずに書けると思います。とはいえAPI Gatewayはエラー原因をちゃんとログ(Cloud Watch)に吐いてくれないので、何か記述に問題があると原因探しは結構大変でした。(スタックトレース吐いてくれてたらどれほど楽だったか……)


 余談ですが、bodyの中身は「input.body」でも取れるんですが、POSTリクエストの送信時にbodyが空っぽだと変換時にエラーになります。「$input.path('$') 」と回避できました。



ちなみに参考にさせて頂いたサイトは以下。上記のマッピングテンプレートも、配列の処理以外はほぼ以下のクラメソさんの記事のものを使わせて頂きました。


インタビューによる「自分半生記」のススメ

IMG_6996

はじめに

 週末にインタビューめいたことをやってきました。

 相手は社外勉強会つながりの知人。コンサルというかコーチというか、まぁそんなような仕事をされている方なんですが、「最近インプットはしてるんだけど、アウトプットをちゃんとできてない。一回整理してアウトプットしたい。」というようなことをSNSでつぶやいてるのを見かけて「面白そうだからケツひっぱたいて強引にアウトプットさせちゃえ!」とばかりにオレから声をかけ、時間確保してガッツリ根掘り葉掘り聞いて書き出して、アウトプットしてもらうための整理をしてもらおうと試みたわけです。

 ……「試みた」と表現したのは、つまり、終わらなかったんですよ、インタビューが。結果面白い話は聞けたし、インタビュイーの方にもかなり満足してもらえたので、それはそれで良かったのですが、本題までたどり着けなかったのは非常に残念でした。

 なぜ終わらなかったのか? それは、今回オレが行ったインタビューが、「その人が生まれた時から今日に至るまで、全て話を聞いていったから」です。今回はインタビュイーの方は4x歳で、まぁそれでも2時間くらいで最後まで行けるかな、と見積もっていたんですが、実際にはインタビュイーの方の話があまりに波瀾万丈すぎて一晩中話しても全然時間が足らなかったですね。まぁオレの見積精度が甘いのはいつものことなのでしょうがないか。

 とはいえ、一応好評だったんで、今回のインタビューでどんなことをやったのかを書き出してみたいと思います。


ルール

 今回行ったようなインタビューは、以下のようなルールに基づいて行いました。

  • その人の生まれた時から聞いていく
    • 出身地は?
    • 家族構成は?
    • ご両親の職業は?
    • 環境は都市か田舎か?
    • etc...
  • 人生の節目を意識して聞いていく
    • 小学校と中学校はセットで考えてOK
    • 高校くらいからその人の選択が見て取れるので、意識して聞いていく
      • 部活や趣味、その頃興味を持っていたものなども
  • 必ず他者がインタビュイーに質問する形式で聞く
    • 意外と自分のこと(≒分かっていること)は端折って喋りがち
  • インタビュイーが話したくないことは聞かない
  • 脱線上等!ユルいスタンスでインタビューに臨む
    • 脱線してもあまり無理に話を戻さない
    • その人の「ひととなり」が把握できることのほうが重要
  • 細かく聞き過ぎない
    • 時間がいくらあっても足らなくなる
    • 掘り下げたいポイントがあれば個別にインタビューを行う

なぜ「半生」をインタビューするのか

 このインタビュー方法は元々、オレが派遣常駐型のSIerで小さな部署を任されていた時に、自分の部下たちに対して行っていたものです。

 その会社では四半期〜半年に一度、自社に戻ってきて部下たちと面談することが各部署の上長に義務付けられていました。それが無くとも、必ず年に一度は人事評価を行う必要があります。
 ところが部下たちと顔をあわせるのはせいぜい月一回程度。これで「人となり」を把握するのはどだい無理ですし、人事評価を行うのも困難です。人事評価に関しては結局「営業から伝え聞いた現場の評判」に頼らざるを得ないのですが、元々大した情報が期待できないうえに伝聞の情報です。はっきり言ってお話にならない。さらに言えば、人事評価も含め、部下の育成責任も背負わなくてはならないのです。現状の能力評価も正しくできない、「人となり」も把握できてない。こんな状態で部署の上長としての責務を全うできますか?出来る奴がいたら、そいつは予言者かイタコです。IT業界なんかにいないで芸能界進出でも考えた方がよっぽど稼げます。

 というわけで、予言者でもイタコでもない凡庸たるオレが取った手段は、部下が自分の部署に就いた一番最初の面談で、それまでの人生含め様々なことを根掘り葉掘り聞いて、その部下の「人となり」をザックリとでも把握する、というものでした。それぞれ部下一人一人から半生に相当するものを聞き、その上で会社の方針や部署の方針、人事評価の方法、今後どういう方向に進みたいか、といった一般的な評価面談の内容を改めて話すようにしていました。

 これをやるとメッチャクチャ時間がかかります。一人あたりの面談時間が2時間なんてのはザラ、場合によっては3時間やってそれでも足らずに居酒屋に移動して延長戦突入、なんてのもありました。
 でもその甲斐もあって、オレの部署は(成果はともかくとして)当時社内で一番活気があって面白いチームでしたし、週末に勉強会なんかを頻繁にやっていたこともあってか、その取り組みが評価されて、リーマンショックで社内全員一律ボーナスカットなんて事態でも、オレのチームだけは全員ボーナスが出た、なんてこともありました。


 その辺の取り組みは以前発表したことがあるので、興味があれば以下のスライドをご覧いただければと思います。




 これは

  • チームが同じ場所で働いていない(多くて月一程度しか顔を合わさない)
  • 部下の人事評価と育成を行う義務がある

という特殊状況下で否応なく迫られて行ったことでした。
 しかし、今回異なるシチュエーション(他者の能力の棚卸の実施)でインタビューを行う場合にも、割と悪くない手法なんじゃないかと思い、今回は採用しました。


 以下は故:スティーブ・ジョブズ氏の有名なスピーチです。このスピーチで個人的に一番大事だと思っているのは、スクリーンショットを貼付した以下の部分です。

スティーブ・ジョブス スタンフォード大学卒業式辞 日本語字幕版


https://www.youtube.com/watch?v=XQB3H6I8t_4

f:id:takigawa401:20170402152450p:plain
f:id:takigawa401:20170402152507p:plain
f:id:takigawa401:20170402152513p:plain
f:id:takigawa401:20170402152518p:plain


 この箇所については「物事はいつか何かしらつながっていくから、将来それが役に立つ・立たないに関わらず、今自分が興味のあることに全力を注ぐべきだ」「役立てるための点と点とをつなぐ努力は後でやれ」とオレは理解しています。過去に起こったこと、体験したこと、学んだことは、大なり小なり何かしら今の自分に影響しているはず。

 例えば、オレは漫画が好きですが、その遠因は

  • 叔母が漫画家だったこと
  • その影響で彼女の生家でもあるオレの実家には、彼女の残していった漫画があふれかえっていたこと
  • 母が元々漫画やアニメが好きで、子供たちからそれを隠したり遠ざけたりしなかったこと

 が考えられます。その結果として、

  1. 親がTVゲームにも理解があり、小中高と楽しくゲームで遊べる環境にあった
  2. ゲームクリエイターになりたくて専門学校に入る(大学に入るよりも近道に感じた)
  3. 元々進学校の出身だったこともあって、そうではない学生向きの授業……特にプログラミングで全く苦労しなかった
  4. 「これだったら独習で十分だな。それよりは教わらないとできないものを学校で教えてもらった方が良さそうだ」とゲーム科からCG科に転科
  5. CG科で教わったWeb・HTMLが面白くなり、そちら側に進路を変更
  6. アルバイトで入った光通信系のホームページ作成会社で、自分にデザインのセンスがまるで無いことを思い知る
  7. Webの知識があり、PhotoshopIllustratorも使えることから、Web系業務システムエンジニアに転身

 という道をオレはたどりました。一見すると無軌道な人生にも見えますが、源流に叔母と母の影響で漫画好きだったこと鑑みると、それなりに筋が通っているようにも見えます。


 このように、今の自分が、過去の何に影響されているかは、意外に今だけ見ていると分かりづらいです。また、分かり易く役立つものだけがつながりになっているとも限らないです。スティーブ・ジョブズの言う「後から振り返って点を点を繋ぐ」のには、洗いざらい過去を漁ってみて、全部平らにして並べてみた方が、より効果的だとオレは思います。



 時間がかかる作業ですし、協力者(インタビュアー)も必要です。やれば必ず成果が出ることは約束出来ませんが、少なくともオレに関してはこれまではそれなりに手ごたえを得ることができていました。仕事や進路で悩んだ時、自分の棚卸が必要になった際には、ぜひ一度試してみて頂ければと思います。



余談

 今回インタビューを行うにあたり利用した店はこちらでした。カウンターメインの店で店員さんが頻繁に話しかけてきてくれるので、一人でも行きやすいんじゃないかと。「アキバで女の子がサービスする店」というイメージを良い意味で裏切られ、料理もお酒も大変美味しかったです。また、我々のインタビューの内容にイイカンジでツッコミをくれたのも面白かったですね。話に夢中になってて肝心の寿司を食い忘れたので、またいづれリベンジしたいです。

www.nadeshico-sushi.com