ミッションたぶんPossible

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

ロジカルシンキングのことを「ロジシン」と呼ぶ営業マンがいた

 ものすっごいロクでもない話なんですが。


 今週火曜だったかな、定時ダッシュして山手線で内輪で開催・運営している社外勉強会に向かっている最中のことです。ちょうど時間は帰宅ラッシュ、社内はかなり混雑しており、オレも吊革で体を支えながらiPhoneでポチポチとソシャゲなんぞをこなしていたんですが、ふと目黒あたりから混雑した車中でも良く通る男性同士の会話が聞こえてきました。ふと声の方に目をやると、いかにも営業マンな男性2人組が、おそらく仕事に関する内容なのでしょう、一方がもう一方に仕事の進め方についてレクチャーしているように見受けられます。その様子はずいぶんと熱を帯びており、周りの混雑もはばからず一生懸命に話していました。


 そんな様子を特に気にも留めず耳にしながら再びiPhoneに目を落としていたのですが、ふとレクチャーする側の営業マンの口から、とても気になる言葉が飛び出してきました。



「だからさ、ロジカルシンキングってのはあの売上表に数字を入れていくためのツールなんだよ!」








 ……………………はぁ?


 一瞬我が耳を疑いました。まさかそんな馬鹿な。でもそれは聞き間違いではありませんでした。その後もレクチャー側の営業マンは同様の内容を繰り返します。聞く側の営業マンも特に訂正もせずにウンウンと熱心に耳を傾けています。挙句の果てには「つまりロジシンをさ!」などと「ロジカルシンキング」という用語を略し始める始末。「ロジシン」なんて略語、聞いたこともねーよオレは!


 やがてオレは品川で電車を降りたので、それ以上その会話を聞くことはありませんんでしたが、精神衛生上それで本当によかったと思っています。




 わざわざ後述するまでもありませんが、「ロジカルシンキング」は「ツール」ではありませんし、ましてや営業上の数字を入れるものでもありません。彼らが使っていた「ロジカルシンキング」という言葉は、明らかに意味が間違っています。Web辞書で調べてみると、以下のように解説されていました。

論理的な考え方と、その技法。

 ― goo国語辞書

ロジカルシンキング(logical thinking)とは、一貫していて筋が通っている考え方、あるいは説明の仕方のことである。

 ― Wikipedia

論理的思考法。物事整理して考え、論理的に筋道立てて、他の人に分かり易く説明する手法。また、その能力のこと。
「スピーディーにスムーズに相手に分かりやすく物事を伝える」こと。コミュニケーション能力を推し量る指標の一つ。

 ― はてなキーワード


 これはあくまで想像に過ぎない(しかも彼らに対してかなり好意的かつ同情的な)んですが、おそらくは彼らの会社もしくは部署で、とあるツールに対し、なぜか「ロジカルシンキング」などという名前をつけてしまったのでしょうね。これが事実であったなら、その命名者のセンスと語彙力は壮絶に残念なものであることは言うまでもありません。かつ、彼らが不勉強で「ロジカルシンキング」という一般ビジネスパーソンにとって割と当たり前(少なくともちょっとWebで調べれば意味が分かる)用語を知らない・他で聞いたことが無いならば、まぁこういったことがあるのかもな、と思いました。思いましたが、彼らが自信満々声高らかにラッシュアワーの山手線で喋った内容が、実は周囲が眉をひそめるようなものであったこと、彼らがビシッと決めたスーツも髪型も胸元のバッヂもすべて台無しにするものであったことは、きっとソッとしておいてあげるべきなんでしょうな。


 さっき上記の記事を読んで、そんなことを思い出しました。ロクに意味も分かってないで横文字使ってる人、非常に多いんでしょうね。オレもこれを他山之石とせず、今後の自戒としたいと思います。だって、あんな格好悪い目に遭うの、オレ絶対にヤだもの!

5/24「AWS Blackbelt Online Seminar Amazon Elastic Compute Cloud (EC2) - Windows」受講レポート

はじめに

 Amazonが配信している「AWS Blackbelt Online Seminar Amazon Elastic Compute Cloud (EC2) - Windows」を受講しました。以下受講メモ。


メモ

Amazon EC2 Windows概要
Amazon Machine Image(AMI)
  • インスタンスとAMI
    • AMI
    • Windows AMI
    • Windows Server 2016 AMIにおける変更点
      • EC2Configサービスが廃止
      • EC2Launchを採用
    • Dockerを利用する場合
      • Base with Container AMIを利用する必要がある
        • 別のAAMIを利用すると正しく起動できない
    • Windows AMIの検索
      • 条件に基づいて検索
        • リージョン
        • OS
        • 32/64bit
        • ルートデバイスタイプ
        • プロバイダ
        • 日本語版はImage Nameに「Japanese」を指定
    • Windows AMIのバージョン
      • いくつかのツールをデフォルトインストール済み
      • MSからの定例パッチを提供後5営業日以内に更新されたWindows AMIを提供
      • Amazon SNSで更新の通知を受信可能
        • 専用の設定が必要
        • 新しくWindows AMIが追加された場合
        • 既存のWindows AMIが削除された場合
インスタンスの設定
  • EC2Configサービスを使用したWindowsインスタンスの設定
    • 2016 Serverには含まれない
    • ユーザーデータの使用
    • Sysprepの実行
  • EC2Launchを使用したWinddowsインスタンスの構成
    • EC2Configを置き換えるもの
      • ほぼ同じことができる
  • ステートマネージャー(SSM Config)を使用したWindowsインスタンスの設定
  • 準仮想化(PV)ドライバの種類
    • 古いドライバ(RedHat PV)が入っていることも
      • 手動で更新が可能
  • Windows OSのアップグレード
    • Windows Server 2016へのアップグレードは未サポート
モニタリング
  • Amazon CloudWatch
    • AWSの各種リソースをモニタリングするサービス
      • メトリクス監視
      • アラーム作成
      • ログ監視
    • CloudWatchへの情報送信
      • ローカル設定ファイル
      • EC2 Systems Manager/ステートマネージャー
  • EC2Rescue
ネットワークとセキュリティ
まとめ
Q&A
  • Visual Studioは使用可能か?
  • 既存インスタンスについては従来通り手動でWindowsパッチを適用する必要があるか?
    • 手動も可能
    • EC2 Systems Managerの設定で自動的用も可能
  • EC2 Systems ManagerでオンプレミスやデスクトップのWindowsに対して操作を行うことが可能か?
    • 可能。エージェントを捜査対象にインストールすることで操作できる
  • Windows Serverに機能制限は?
    • 基本的には無いが、EC2の制限として共有ディスクやマルティディスクには対応できない。

感想

 オレ、Windowsサーバって、これまでの案件でほんの数案件でしか使ったことないんですよねぇ。特に自分がインフラ触るようになってからはLinuxオンリーです。今後もWindowsサーバに触ることはあるのだろうか……?
 それはそれとして、EC2 Systems Managerについてはとても強い関心が持てました。実はAWSではサーバレス構成のプロジェクトでしか開発したことがないので、EC2はまだ触ったことが無いんですが、こういったツールは積極的に活用していきたいです。

5/23「AWS Blackbelt Online Seminar AWS認定試験準備に向けて」受講レポート

はじめに

 Amazonが配信している「AWS Black Belt Online Seminar AWS認定試験準備に向けて」を受講しました。以下受講メモ。


メモ

  • AWS任手プログラム紹介
  • 準備作業の紹介
イントロダクション
  • AWSクラウドの現状を紹介
  • AWS認定
    • エキスパートの証明
    • キャリアアップ
    • 名刺にAWSを貼れる
    • コミュニティ参加
  • AWS認定保持者
    • 高い年棒だよ
    • 技術的な信頼獲得に役立った
    • 同僚から頻繁に相談されるようになった
  • 認定プログラムについて
    • ソリューションアーキテクト
      • DevOpsエンジニア
    • デベロッパ
      • DevOpsエンジニア
    • システムオペレーションアドミニストレーター
      • DevOpsエンジニア
    • それぞれに
      • アソシエイト
      • プロフェッショナル
  • 認定要件
    • 各試験に合格
  • 申込
    • AWSサイトにて
  • 申込後キャンセル
    • 72時間前までなら無料
    • 以降は9000円の手数料発生
  • 持ち物
    • 身分証明書
    • 認証コード
    • NDAの事前確認
  • 試験結果
    • 即時通知
    • 14日以降であれば再受験可能
    • 同じ試験を1年以内に3回受験可能
  • 再認定
    • 2年以内に再認定試験に合格
    • より高いレベルの試験に合格
試験内容について
  • 必要な知識と出題範囲
    • AWSサイトにて確認
    • 必要なAWSの知識
    • 必要なIT全般の知識
  • 出題分野
    • 料金の詳細等変化が頻繁なものは範囲外になりやすい
    • 頻繁に使わない機能は範囲外になりやすい
  • 回答方法
    • 4つ以上の選択肢から設問に最も良くあてはまるものを選択
      • 択一
      • 複数選択(選択数は設問に明記)
試験準備
  • 認定試験の最善の準備は実践的な準備
  • 学習に役立つ準備マテリアル
    1. トレーニングクラスの受講
      • 3日間
      • 21万円
      • 個々のシステム構築
      • ベストプラクティス
      • 身分証明書の持参が必要
    2. 認定試験ガイド・サンプル問題の確認
      • AWSサイトより
        • 先にサンプル問題を読んで、自分の苦手を把握した方がよい
    3. QwikLABS
      • オンライン学習環境
        • クレジットカード登録が必要
        • 一部は無料
    4. AWSホワイトペーパー
      • AWSサイトより
    5. AWS FAQ
      • AWSサイトより
    6. 認定試験準備ワークショップ
      • AWSサイトより
    7. 模擬試験
      • AWSサイトより
      • 回数制限なし
        • 同一の問題が出題される可能性がある
    8. 認定試験
その他リファレンス
  • AWS初心者向け学習リソース
    • オンライン動画
    • AWS製品ページ
      • 特徴
      • 料金
      • 開始方法
    • AWSドキュメント
    • Blog
    • AWSの最新情報
    • AWS Answers
    • AWSサポート ナレッジセンター
    • セミナー
      • 国内のセミナー
      • オンラインセミナー
      • セミナー過去資料
    • イベント
      • AWS re:Invent
      • AWS Summit Tokyo
        • 新サービス発表
        • テクニカルセッション
        • 事例セッション
        • パートナー事例
        • 認定試験の受験も可能
          • 50%ディスカウントクーポン(次回から活用)

感想

 まぁそんなに特筆すべきこともないのですが。
 会社の今期の自身の評価基準に、うっかり「1つ以上のAWS認定資格の合格」を入れてしまったものだから、ぼちぼち(つまり6/末までに)受験しなくちゃいけないんですけど、そういえばちゃんと調べてなかったなぁと思って、ザックリ把握するために受講してみました。いやー、やること多いですね。本当に残り1月で合格できるのか、オレ? 元々あまり資格取得に興味が無いので、正直放置できるなら放置しておきたいところなんですが、そうも言ってられないので、とりあえずトライだけはしてみようかなと思います。


 そういや、今回のオンラインセミナーは女性の方が講師でした。今まですべて男性だったから珍しいですね、内容も技術者向けバリバリって感じでもないので、営業さんだったりとかしたのかしら?

Amazon AthenaでCloudFrontログを解析しようとしたらエラく苦労した話

 この2日間、さんざん悩んだので、メモメモ。


 Amazon AthenaはS3に格納したログファイルとかを、まるでRDBのようにSQLで検索・分析できる、いわゆるサーバレスなサービスです。
このAmazon Athenaで、S3→CloudFront経由でダウンロードしたファイルのアクセス数をカウントするような簡単な分析を行いたい、というのが今回の要件。CloudFrontはS3にgzip形式(拡張子:「.gz」)でアクセスログを吐くので、こいつを無加工(gzipを回答したりファイル群を結合したりせずに)で検索できるあたりがAmazon Athenaとても便利なところです。


 Amazon Athenaは割と最近リリースされたばかり(「AWS re:Invent 2016」で発表)なので、社内に知見もなく、Webの記事を参考に構築を試みました。……がこれがどエラい苦労しました。


 参考にすべきものがあって何故苦労したか? これじゃまともに動かなかったからです。各記事のテーブル作成SQLでテーブルを作ると、なぜかログファイルのレコード行が空白で取り込まれ、ヘッダー行が1カラム目がやはり取り込まれない状況でした。


 結論から言うと、以下のSQLで正しくテーブル作成ができました。カラム名を「` (アポストロフィ)」で囲む必要があったのです。今回はSQLを直接エディタに書くのではなく、コンソールからチマチマ入力してテーブルを作った際、このSQL文が生成されたことで違いに気づけました。

CREATE EXTERNAL TABLE IF NOT EXISTS cloudfront_log (
  `date` date,
  `time` string,
  `x_edge_location` string,
  `sc_bytes` int,
  `c_ip` string,
  `cs_method` string,
  `cs_host` string,
  `cs_uri_stem` string,
  `sc_status` int,
  `cs_referer` string,
  `cs_user_agent` string,
  `cs_uri_query` string,
  `cs_cookie` string,
  `x_edge_result_type` string,
  `x_edge_request_id` string,
  `x_host_header` string,
  `cs_protocol` string,
  `cs_bytes` int,
  `time_taken` int,
  `x_forwarded_for` string,
  `ssl_protocol` string,
  `ssl_cipher` string,
  `x_edge_response_result_type` string,
  `cs_protocol_version` string 
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe'
WITH SERDEPROPERTIES (
  'serialization.format' = '	',
  'field.delim' = '	'
) LOCATION 's3://sample-cloudfront-log/logs/'
TBLPROPERTIES ('has_encrypted_data'='false')

※S3バケット名は記事記述用のでたらめなものです。ご注意あれ。



 参考にした記事らは以下。参照した記事のうちのほんの一部です。


 これらの記事の内容が間違っていた、とはオレは思いません。何故なら、同時期に書かれた記事で同じようなSQL文が書かれており、実際に検証した結果の画面スクリーンショットも張り付けられていたからです。
 おそらくは、かなり直近……おそらく昨日今日のレベルで、Amazon Athenaで仕様変更があったんじゃないでしょうか? 詳細は分かりませんが、今後突然CloudFrontログ分析がAmazon Athenaで行えないケースが増えそうな気がしたので、自分用のメモを公開しておきます。


※何か誤りあればご指摘頂けますと大変助かります。

「AWS Black Belt Online Seminar AWS for Game Developers」受講レポート

はじめに

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

メモ

講師
  • 畑 史彦さん
ゲームの進化とゲーム開発
  • ゲームの進化
  • 複雑化・高度化・大型化するゲーム開発
    • プラットフォームの多様化
    • クオリティ上昇=コスト上昇
    • マルチプレイヤーゲーム
    • ユーザーのエンゲージメントを高める仕組みが必要
    • 開発プロジェクトの大規模化
Amazon Lumberyard
  • Cloudとccrowdの力を活用しAWSとTwitchを深く統合させた無料のAAAゲームプラットフォーム
  • AWSと非常に深く統合
  • 共通のネットワーク接続を簡単に作成
  • 新しい・素晴らしい体験
    • 手続き的なゲームプレイ
    • 人工知能
    • 多くのプレイヤー
  • クライアント - エンジンプラットフォーム
  • Lumberyard Editorの基本機能
    • 基本的なゲーム開発に必要なものは大体そろってる
  • レンダリング
    • 非常にきれいなレンダリングを実現可能
    • HDRサポート
    • 物理ベースシェーダー
    • ダイナミックライティング
    • etc...
  • モバイルサポート
  • VR
    • サポート
      • OCulus
      • Vive
      • OSVR
      • PSVR
    • エディタからのインスタントVRプレビュー
    • モジュラーVRフレームワーク
    • 360度ビデオ再生
  • ワークフロー
    • Windowsエディター
    • 新しいComponent Entity Sysytemが非エンジニアに新しい権限を
    • C++, Lua Visual Scripting
    • etc...
  • New IDE
  • Component Entities
  • Gem
    • Lumberyardのゲームプロジェクトをっ拡張するためのコードやアセットが含まれているパッケージ
    • 現在Lumberyardには、すぐ利用できる26のgemが用意されている
  • Modular Gemシステム
    • ゲームプロジェクト間でコードとアートアセットを共有するための管理インフラストラクチャ
    • プロジェクトのコンテンツの追加と削除が容易にできる
      • コアエンジン部分は必要なテクノロジーのみに
  • UI Editer
  • GridMate
  • CloudCanvas
    • クラウドリソースを利用したゲーム機能を構築・管理
      • クラウドセーブ
      • ニュースティッカー
      • リーダーボード
      • アチーブメント
      • キャラクター状態保存
      • etc...
    • バックエンド経験がほとんどないエンジニアでも構築可能
      • ニュースフィードなど
    • ビジュアルスクリプティングIFを搭載
    • Lumberyardとセットで簡単に利用可能
    • CloudCamvasから利用するAWSリソース
    • Lumberyardとっクラウドの間を糊付けするような役割
    • Cloud Canvasリソースマネージャーで管理
      • AWSリソースを定義
      • スタックを生成
      • ローカル作業
      • 使用しているAWSリソースを維持
      • 安全なリソース使用
  • Cloud Gem Framework
    • 1人のエンジニアが30分でクラウドコネクティッドなオンライゲーム機能を構築可能
    • Cloud Gems
      • クラウドコネクティッドなオンラインゲーム機能を提供するGem
        • デイリーメッセージ
        • リーダーボード
        • 動的コンテンツ配信
        • ユーザーアカウント認証
    • Cloud Gem Portalでチームの誰もがCloud Gemで作成された機能を管理できる
      • Cloud Gemを管理するためのGUIポータル
      • 実態はS3に配置された静的コンテンツとLambda・Amazon API Gatewayからなるサーバレスアプリケーション
  • Lumberyard IDE
    • システム要件
    • 料金
      • 無料
      • Cloud Canvasなどの利用時に使用料が発生
    • ライセンス
      • Not Opensource
        • 修正・改修は可能
        • 外部公開は不可能
      • AWWSで代替できるような外部のサービスには利用不可
Amazon GameLift
  • セッションベースのマルチプレイヤーゲーム専用のゲームサーバ管理サービス
    • 設計
    • プロトタイプ構築
    • 本番環境構築(複数回)
    • スケーリングに関わるたちの悪い問題
    • UIダッシュボード構築
    • リリース
    • 24/365保守
    • コストの最適化作業
  • ビルドとフリート
  • 開発者のワークフロー
  • 開発環境
    • AWSアカウント
    • Lumberyardのゲーム
    • ネットワーク
  • 開発ステップ
    • 4ステップで実現可能
  • デプロイ
    • プレイヤーから透過的
    • 進行中にゲームプレイに影響しない
    • Alias
      • フリートによりプレイヤーの乳流を制限
  • セッション管理
    • 稼働している世界中のゲームサーバーを継続的にスキャンし、プレイヤーからのゲーム参加リクエストをマッチング
  • リアルタイムで情報を把握
  • 世界展開
    • 9リージョンから配信可能
  • オートスケーリング
    • ルールベース
    • リアルタイムな利用可能量に基づく調整
  • 利用料金
    • 従量課金
  • 採用事例
    • STREAM LINE
      • Proletariat Inc.開発
  • Unreal Engine,Unityを含むすべてのC++/C#ゲームエンジンをサポート
  • Amazon GameLisft Local
Twitch
  • ソーシャルビデオプラットフォーム・コミュニティ
  • 新しいゲームプレイ体験を提供
    • 視聴者がゲームに参加
      • チャットコマンド
      • 配信者からの招待
      • ゲーム画面にゲーム状況をオーバーレイ
amazon.com
  • ECサイトと連携し販売プラットフォームを提供
    • Amaozn.com
    • Androidアプリストア
まとめ
  • ゲーム開発者向けのEnd-to-Endソリューション
  • インフラ管理に労力を割くのではなく、コンテンツ制作とゲーム制作に注力できる

感想

 オレ自身、ゲームを開発したことはないですし、その予定もないのですが、今回はAWSの提供サービスをざっくり把握することを目的に聴講しました。聞いている限りでは、確かにインフラに関わる部分をかなり省力化できそうな印象を受けました。ソーシャルゲームなんかは当たり外れが大きいので、オンプレで1からやるよりはこういうプラットフォームを開発・運営に活用するのは良さそうですね。グランブルーファンタジーのような超大規模ソーシャルゲームは、クラウドだと調整しきれないのでオンプレで運営しているという資料を読んだことがありますが、あそこまで大規模になるかどうかはリリースしてみないと分からないでしょうし、まぁ別物と考えていいんじゃなかなと思います。


 さて、それじゃあオレは四象降臨(グラブルのイベント)に戻るかな。

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と連携できるサービスも増えるようですので、今後とも活用していきたいです。