JJUG CCC 2018 Fall 行ってきました！参加レポート

Java JJUG コミュニティ活動

JJUG CCC 2018 Fall http://www.java-users.jp/ccc2018fall/#/www.java-users.jp

↓朝8時半、爽快に晴れ、朝日が差し込む四谷駅から新宿二丁目西新宿に向かう f:id:yasay:20181217130733j:plain

f:id:yasay:20181217124225j:plain:w350

今年の冬もやってきました❗️JJUG CCC 2018 Fall❗️
所用があり午前中だけの参加でしたが、とても有益な情報を得られ、
おかげさまで参加したメリットがとても大きかったと思います❗️😃

レポートしていきます！📝

レポート📝

10:00 - 10:45 Spring BootのWebアプリケーションをDockerに載せてAWS ECSで動かしている話

www.slideshare.net

  • DDDとクリーンアーキテクチャの人(前回の登壇は見てた)
  • システム構成
    • 企業向けWebサービス、取り扱うデータ量は多い(数百GB~数TB)
    • ALB -> WEB UI Container -> in ALB -> other containers
    • in ALB -> independent EC2の流れもある
    • ECR -> ECSの王道を行く
    • CodeDeploy, GitLabを利用してECRに登録
    • 採択経緯
      • 学習コスト懸念、Fargateのランニングコスト懸念
      • (ECSでやっておけばFargateへの切り替えは比較的容易・・)
    • (Web)ALB -> Web Server Container -> UI Container
      • 本当はUI Containerの前にALBを挟みたかった
        • X-Forward-For, X-Forwarded-Proto, X-Forwarded-Portが書き換わる
        • リダイレクトURLのポートが変わっちゃう問題があった
  • 開発環境
    • メモリ16GB, Windows派多数、Macな人も
      • マージリクエストを利用
      • ローカル用プロファイルで動作させるSBが入ったDockerコンテナをビルド・起動
      • 他マイクロサービスのところはモック化
    • GitLab CIで開発環境にデプロイ
      • jarビルド -> Dockerイメージビルド -> ECRに登録 -> ECSのタスク定義 & サービス更新 -> Mattermostに通知
      • すぐにデプロイされない罠
        • ec2数 > タスク数：すぐにデプロイされる(新しいインスタンスに)
        • ec2数 = タスク数：1個止めに行っている間は待たされる
    • 環境毎の切り替え
      • β環境1 -> β環境2 -> β環境3
      • 性能ってのは測ってみるしかない！
      • プロファイルの切り替え
      • Git Flowを採用
      • ECSの環境変数をだけで動作設定を変更できる。
  • ログ出力
    • Kinesys Data Firehorseに連携、S3に保存して分析
  • アクセス監視
    • 未解決事件
      • コンテナ間通信が502エラー
        • ALB <- -> コンテナ
    • ECSはDockerコンテナを間違って落としちゃったとしても瞬時に検知して復旧できる仕組みがあるからそこがすごい。

11:00 - 11:45 Java + コンテナ向けパフォーマンス分析手法の紹介と活用事例

https://jjug-cfp.cfapps.io/submissions/2674d2b0-9b8e-415a-bb3f-75e56333330b

  • 最小の変更点を発見し、速度を改善したい。
    • JMeter & APP DYNAMICS
    • APMでもモニタリング
    • プレリリース環境での継続的な負荷テスト
  • ボトルネックの発見
  • だれでもやること
    • ログをいい感じに仕込む
    • VISUALVMをつなぐ
    • FlightRecorder?
      • system, libc, Native library, GC, JIT?
      • perf-toolでサンプリング
  • 事故は起こってから観測しても遅い
    • perf-scriptは重い
    • perf-recordは比較的軽い
  • Interpreterによる分裂の障害
  • 利用しているツールなど
  • Off-CPUの自動解析は難しい
    • wPerf (Zhou et al)

f:id:yasay:20181217130337p:plain

@nakayama_sanの可愛いメモ

紹介せざるをえない！JJUG CCCでいつも可愛いメモを共有してくださっている、
@nakayama_sanのツイートです！

所感

ECSの環境変数を便利に使えるという話はとても有益でした。

[2018/12/19追記]
本イベントの後にAWSから発表があり、
SSM Parameter Storeの値の参照が Fargate から可能になったようです。

Avalancheについても是非とも実際に動かしてみて、
パフォーマンスを解析したいと思っています。
スター数とかも増えて是非とも盛り上がって欲しいOSSですねぇ。

短い時間での参加でしたが、本当に参考になるセッションばかりで感謝です！
見れなかったセッションは、TwitterやGitHubを通して、各セッション情報を参照し、
確認したいと思います！

GitHub - jjug-ccc/slides-articles-2018Fall: JJUG CCC 2018 Fall 登壇資料まとめ

↓写真はおなじみの成子天神社の一コマ。今回も牛さん撫でできました 🐮 f:id:yasay:20181217130623j:plain f:id:yasay:20181217130638j:plain

以上です！

AWS SAMの「AutoPublishAlias」の使い方を誤るとエイリアス消えちゃうよっていう話

aws

AWS Serverless Application Model(SAM)には「AutoPublishAlias」という設定があります。
docs.aws.amazon.com

- AutoPublishAlias: By adding this property and specifying an alias name, AWS SAM:
  - Detects when new code is being deployed, based on changes to the Lambda function's Amazon S3 URI.
  - Creates and publishes an updated version of that function with the latest code.
  - Creates an alias with a name that you provide (unless an alias already exists), and points to the updated version of the Lambda function. Function invocations should use the alias qualifier to take advantage of this. If you aren't familiar with Lambda function versioning and aliases, see AWS Lambda Function Versioning and Aliases .

AutoPublishAliasを有効にした場合、
Lambdaファンクションのソースコードに変更があった場合はリパッケージされた
Lambdaのバージョンが発行され、指定したエイリアス名とバージョンが紐づくように設定されます。

今回、この「AutoPublishAlias」を利用して、
Lambdaのエイリアスを複数管理しようとしてうまくいきませんでした。
何故うまくいかなかったのか、「AutoPublishAlias」の挙動結果を述べつつ下記に記します。

エイリアス名を変更した時は、変更前に指定したエイリアスが消える

下記の画像のように「dev」が指定されているとします。
これを、「prod」に変更してデプロイしてみます。
f:id:yasay:20181213163719p:plain

すると、「dev」エイリアスが消えて、「prod」エイリアスのみが残りました。
「dev」エイリアスが削除されてしまったんです。
f:id:yasay:20181213163807p:plain

「AutoPublishAlias」をコメントアウトすると、変更前に指定したエイリアスが消える

例えば、下記の画像のようにエイリアス指定をコメントアウトすると・・
f:id:yasay:20181203165003p:plain

エイリアスが消えてしまいます。
f:id:yasay:20181213165309p:plain

絶対消しちゃダメなエイリアスをSAMで指定するのは不安かもしれない

私はAlexaカスタムスキルで利用するエンドポイントにLambdaのエイリアスを利用しています。
例えばAuboPublishAliasで「Prod」が指定されている状況から「dev」に切り替えた時に、
想定外の処理がAlexaカスタムスキルで実行されることになります。

つまり・・私のエイリアスの使い方・・間違っている？
f:id:yasay:20181213154441p:plain

一つのLambdaファンクションにおいて、エイリアスを指定して開発や本番を指定したい時はどうするべきか

消えちゃいけないエイリアス(prodなど)は個別にエイリアスを発行。
それ以外は$LATESTを参照すればよいと思います。

つまり・・私の運用では「AutoPublishAlias」の設定は不要ということです。

・・・じゃぁ、そもそもAutoPublishAliasってどこで使うの？

API Gatewayなどで指定されているLambdaエンドポイントに
エイリアスが指定されている状況において、SAMテンプレートの更新と同期する形で、
エイリアスとバージョンの紐づけを付け替えたい状況ですかね。

今の私のAlexaカスタムスキルのように
一つのLambdaファンクションで環境を分ける用途になりますと、
最新のバージョンが「prod」エイリアスなどの本番環境に適用されちゃいけないんです。
つまり、私の利用ケースには適さないということですね。

もちろん、一つのLambdaファンクションで開発や本番を定義するという私の考え自体が、
ベスト・プラクティスに則ってない可能性は否定できません。

しかしながら、APIゲートウェイにステージという概念があるように、
Lambdaにもステージという概念があってもいいと思うんですよ。
それを実現するためにエイリアスと「AutoPublishAlias」を活用しようとしていました。

今回の調査により、「AutoPublishAlias」も結局のところ適材適所のパラメータなのだと思いました。
いいアウトプットにはなりました！

以上です！

技術情報をGoogleで検索する時に英語のインプットを増やす方法

テクニカルナレッジ

プログラマやエンジニアの技術情報は、まず最初に英語でやってきます。

しかしながら、普段何気なくGoogle検索を利用していると、
日本語の検索結果が多く混じってきます。

個人的には、まず英語でInputを吸収、
その後に日本語のドキュメントがあれば吸収していきたいと
思っていますので、そのための設定をエントリーします。

PCの場合

Googleアカウントと連携していないChromeユーザを作成して検索する。

その時、Googleの検索設定を英語に変更するようパラメータを付与して、
ブックマークに登録しておくことがおすすめです。

# 以下のURLをブックマークとして登録
https://www.google.com/webhp?gl=us&hl=en&gws_rd=cr&pws=0

Androidの場合

上記の英語検索用URLを異なるブラウザで開く

Chromeで英語検索用のURLを開いても、日本語のGoogleアカウントが紐付いている場合に
やはりノイズが混じってしまうようで。私はDuckDuckGoを利用しています。
play.google.com

英語のインプットを増やし普段から英語と接することは、
エンジニアにとってメリットしかないと思います。

以上です！

JJUGナイトセミナー「Oracle Groundbreakers APAC Tour in Tokyo」のセッション「Microservices Gone Wrong!」レポート

Java JJUG コミュニティ活動

エキスパートを招いたナイトセミナーですごく良質なセッションが聞ける勉強会でした。
今回はイベントスタッフとして参加しました。
jjug.doorkeeper.jp

[Java Track]の最後のセッション「Microservices Gone Wrong!」に参加することができたのでレポートしていきます。

「Microservices Gone Wrong!」レポート

私たちはAmazon / Nettlixから何を学ぶことができますか？

f:id:yasay:20181115105915j:plain

  • コスト削減や過度の構造化に最適化されていない
  • コスト削減の代わりに先取りに重点を置く
  • 市場へのスピードに焦点を当てる（最初のムーバーの優位性）
  • 狂気の成長を助長するために自然のように組織された
  • クラウドは戦略的な利点です！

私たちはAmazon / Netflixのふりをするべきではないのですか？

f:id:yasay:20181115111532j:plain

  • ほとんどの通常の企業は、コスト削減とリストラを求めています
  • ほとんどの普通の会社はAmazon / Netfixの規模を持っていません
  • ほとんどの通常の企業は、コストを節約する方法としてクラウドをまだ見ています
  • あなたがふりをするならば。あなたは無料でインフラの問題をすべて解決します

Microservicesを成功裏に採用した企業は...

f:id:yasay:20181115112129j:plain

  • ...彼らは金融/ヘルスケア/トレーディング/ショッピングサービスを提供するIT企業であると判断した
  • ...クラウド（技術）を戦略的優位性として受け入れる
  • ...固体のCl / CDプラクティスを確立し、1日に複数回プロダクション環境にデプロイ
Companies that have successfully adopted Microservices have...
- ...determined that they are an IT company which happen to offer financial/healthcare/trading/ shopping... services
- ...embraced Cloud (technologies) as a strategic advantage
- ...established solid Cl/CD practices, and deploy to production multiple times per day

実際にはどういう意味ですか...

f:id:yasay:20181115112847j:plain

  • 組織がソフトウェアアーキテクチャと互換性があることを確認する
  • あなたの（マイクロサービス）アーキテクチャがあなたの組織が構造化されている方法を反映していない場合、その方法を気にしないでください！
  • それはあなたのチームがクロスファンクショナルでなければならないことを意味します。構築、維持、生産に必要なものはすべてチームの一員でなければなりません
What it actually means...
- Make sure the organization is compatible with the software architecture
- If your (microservices) architecture does not reflect the way your organization is structured, dont even bother going that way!
- It also means that your teams should be cross-functional. Everyone you need to build, maintain and get it into production must be part of the team

マイクロサービスを正しく行うための単一の方法はありません！

f:id:yasay:20181115112910j:plain

There is no single way to do microservices right!

Struggles

f:id:yasay:20181115112932j:plain

  • データ戦略
  • （非）同期プログラミングモデル
  • オーケストレーションとコレオグラフィー
  • トラップを再利用する
  • テスト戦略
  • 失敗に対処する
Struggles
- Data Strategy
- (A)synchroncus programming model
- Orchestration vs Choreography
- Re-use Traps
- Test Strategy
- Dealing with Failure

A truly, asynchronous...

f:id:yasay:20181115112956j:plain

真に非同期で、完全に分散されたイベント駆動型アーキテクチャは、心配気のないものではありません！

A truly, asynchronous, fully distributed, event-driven architecture is not for the faint of hearted!

分離

f:id:yasay:20181115113022j:plain

  • バルクヘッドを適用してカスケード接続を避ける
  • 転送中には、プロセスを区画に分割し、違反があった場合には封鎖することができます
  • ソフトウェアでは、カスケード接続によるシステム全体の不具合を防ぐためにサービスを分離する
Isolation
- Avoid cascading failures by applying bulkheads:
- In shipping: partition the load into sections allowing you to seal them off if there is a breach
- In software: isolate services to prevent cascading failures to cripple the entire system

ルーズカップリング

f:id:yasay:20181115113053j:plain

  • 障害ユニット間の結合を減らす
    • 非同期通信
    • 場所の透明性
    • 緩やかな時間的制約
    • 偶数性
    • 自己封じ込め
Loose-coupling
- Reduce coupling between failure units through
  - asynchronous communication
  - location transparency
  - relaxed temporal constraints
  - idempotency
  - self-containment

レイテンシ制御

f:id:yasay:20181115113118j:plain

  • タイムリーでないレスポンスを検出して処理し、カスケード障害を回避します。
    • タイムアウト
    • 回路ブレーカ
    • ファンアウト＆すばやい返信
    • 束縛されたキュー
    • シェッドロード
Latency control
- Detect and handle non-timely responses to avoid cascading failures through:
  - Timeouts
  - CircuitBreaker
  - Fan-out & quickest reply
  - Bounded queues
  - Shed load

脆弱性

f:id:yasay:20181115113144j:plain

Anti-fragility
- Try to make code less breakable by correctly applying:
  - Encapsulation (OOP)
  - Open/Closed principle
  - Test Driven Development (TOD)

Microservices are NOT...

f:id:yasay:20181115113211j:plain

マイクロサービスは、あらゆる組織のエンタープライズアーキテクチャの論理的な次のステップではありません

Microservices are NOT the logical next step for enterprise architecture in every organization

Microservices are...

f:id:yasay:20181115113237j:plain

  • 独立して導入可能なサービスのスイートで、ビジネス機能を中心に編成
  • あなたの頭の中に収まるように十分小さいので、それらを捨てることができます
  • システムレベルでのモジュール性の促進
  • ..継続的な展開で繁栄します。 DevOps、およびインフラストラクチャー
  • いくつかの組織でビジネスの機敏性を達成する正当な方法
  • 間違った理由のために適用されたとき悪夢が永遠に起こります！
Microservices
- ..are suites of independently deployable services, organized around business capabilities
- ..are small enough so they can fit in your head and you can throw them away
- ..are all about promoting modularity at the system level
- ..are thriving on continuous deployment. DevOps, and infrasructure auicomaticn
- ..are a legitimate way of achieving business agility in some organizations
-  ..will cause nightmares forever when applied for the wrong reasons!

所感

Microservices関連は日本でも多くの登壇資料が存在していて、それだけ注目を集めています。
ユースーケースにおいて、日本人も海外の人も同じような内容を共有しているなと感じました。
それだけ、日本と海外でMicroservicesに関する認識齟齬が少ないということなのかもしれませんね。

↓の写真はOracleのサーバラックと明治神宮野球場。
こういう機会がないとサーバラックはなかなか拝めないかも。
f:id:yasay:20181115113927j:plain:w350

f:id:yasay:20181115113947j:plain

以上です！

AWS Dev Day Tokyo 2018 行ってきました！参加レポート

aws コミュニティ活動

行ってきました！AWS Dev Day Tokyo 2018！
f:id:yasay:20181113081600j:plain:w350

今回は10/31のLT大会にて、
「AWS DMSで5億レコードを移行して知り得た勘所」というタイトルでLTさせて頂きました！
※LT資料については公開許可をもらっていないので、今のところは公開予定はありません。

参加したセッションについてレポートしていきます！

10/31(水) セッションレポート

14:00-14:40 The Twelve-Factor Appで考えるAWSのサービス開発

www.slideshare.net

  • Rate Limitを考慮
    • Rate Limitを超えるとスロットリングされ、リクエストがエラーを返却する。
    • Rate Limitを把握し、上限緩和申請を行おう。
  • Exponential Backoff And Jitter
    • リトライに遅延(Backoff)とゆらぎ(Jitter)を導入する
    • AWS SDKでの既に実装があるので参考にして実装する
  • ビルド、リリース、実行の3つのステージを厳密に分離する。
  • ステートレス／シェアードナッシング
    • データストアはバックエンドサービスに
    • ELBのスティッキーセッションは利用しない
    • 共有データストアを作らない

15:00-15:40 外部に依存したコードもテストで駆動する

speakerdeck.com

  • まずは現状確認
  • テスタビリティをこじあける
  • aws-lambda-mock-context
  • ランダムなテストの確認方法
    • テストのことを考えてこなかったコードは、テストが書きにくい。
    • 接続部(Seam)を作る
      • 渡された変数でランダム性をぶっつぶす変更をテストコードに加える
  • 設計はよくなっているか？
    • リファクタリングが射程に入っていないテストコードになっちゃっている。
    • テストでは品質は上がらない。テストはきっかけ。品質を上げるのはプログラミング。
  • ビジネスロジックをLambdaから引き離す -> モデルを分離する
  • 状態遷移もモデル自身が判断できるようにする
  • レガシーサバンナ(w)

11/2(金) セッションレポート

10:20-11:00 マイクロサービス化デザインパターン

www.slideshare.net

  • マイクロサービスとは
    • システム全体の変更速度を上げる。
    • アジャイル
    • モノリシック・クラウド・DevOps
    • NoOps = 運用作業込みでプラットフォーム化
  • Cloud Native Architecture
  • 誰もが最初はマイクロサービスではなかった
    • 2011年ぐらいに「マイクロサービス」と名付けられただけ
    • 1チームで複数サービスを管理することは問題なし
    • XPの開発プラクティスは基本
  • 導入ステップ
    • 段階を進めていく
      1. 最初のサービスを分割する。Monolithicから切り出す。
      2. サービス基盤を整備する
      3. サービスを管理する
  • 最初のサービスを切り出す(Step1)
    • リリースサイクルを早めたい場所を切り出す。= ビジネス視点で整理を行う
      • 変更要求が多いところ
      • 複数の機能を横断する場合があるため注意して整理
        • WebAPI連携が定石
        • URLベースの置き換え -> 共有メモリでの認証情報共有が課題
        • データの分割は避け、共有データベースから
          • メリット：コスト最適化
          • デメリット：データベースに関する変更では同期が必要、テーブル共有やビュー経由共有
        • 新サービスにはPaaSを採用 -> 運用作業が自動化されるが、PaaSの成約に従う必要がある
  • 金が儲かるか儲からないかという話でマイクロサービスを切り出すことが大事！？
    • エンジニアがどうだとかそういう話ではない。サービスの分割はビジネス視点で決定すること。
    • 技術的に無理しすぎない。
  • サービス基盤を整備する(Step2)
    • 疎結合に保つための基盤づくり
      • 認証のSSO化(OpenID Connectなど)
      • ログ基盤の導入
      • 非同期キューの導入
      • DBインスタンスの分離(疎結合化) - 不整合をどうするのかが大事
      • 環境設定の外部注入
    • 分割と集約のバランスを考える
  • サービスを管理する(Step3)
    • コンテナ化
      • バッチサーバの廃止 -> 起動するタイミングでノードを手配する
      • サービスメッシュの導入
    • イベントソーシングの導入
  • 新しい技術を使いすぎてオーバーキルになりがちなので気をつけましょう！ということで・・。

13:20-14:00 マイクロサービス時代の認証と認可

www.slideshare.net

  • 認証と認可の基礎知識
    • 認証 通信の相手が誰なのか確認
    • 認可 リソースアクセス権限を与えること
    • 401:認証の失敗, 403:認可の不足
    • WHAT YOU ARE, WHAT YOU HAVE, WHAT YOU KNOW
    • Basic認証(disられ杉), Digest認証(API認証には不向き), リクエスト署名(標準化が足りない), OAuth 2.0(複雑さを覚悟せよ)
    • リソース三役が分離している？ -> 静的・無期限クレデンシャルを許容できる？ -> 独自仕様でいい？策定・実装できる？
  • ユーザの認証とシステムの認証
    • APIの制御について、「データは消費者のモノ説」という考え方で設計
    • Aさんからの許諾があった場合のみという考え方
  • OAuth 2.0とマイクロサービス玉突きの認証認可
    • 所有者, 利用者, 管理者という考え
    • ユーザーと、その権限委譲を受けたクライアント両者の認証が可能になる。
    • ユーザーの介在しないクライアント単体によるアクセス認証も可能です。
    • 玉突きアクセス
      • Access token propagation(S3がWebからだと錯覚する)
      • Client credentials grant(ユーザーの後ろ盾情報が消える)
  • OpenID Connect 1.0とマイクロフロントエンド
    • AWSはMSAのお手本
    • 統一されたLook and Feel
    • SSO(Single Sign-On)
      • 認証サーバーに対するログインセッションが良い

14:20-15:00 Backends For Frontends 入門

speakerdeck.com

  • BFFとは
    • フロントエンドのためのバックエンドサーバー
    • Sam Newman
  • BFFがやること
    • API Aggregation
    • Session Management
    • (Server Side)Rendering
    • File Upload
    • WebSocket/LongPolling/SSE
  • Twitter
    • 最初はMonolith
    • Scala化 -> MicroServices
    • to BFF
  • Netflix
    • 2012にはBFFを活用 : Client Adapter Code
  • Recruit Technologies
    • BFFをNode.jsで構築
  • BFF導入するとき
    • 疎結合にして今後のエンハンス速度を上げたい
    • 先程あげたユースケースのような処理が必要
    • レガシーなシステムが既に存在しており、それを上にかぶせて段階的にリアーキテクトしたい
  • しないとき
    • フロントとバック両方を開発できる人が多い
    • マーケットインを速めることを優先する
    • 上述したユースケースが求められることが少ない
  • BFFのアンチパターン
    • Dividing frontend from backend is an antipattern
      • なわばり意識的な
      • BFFは組織の接合点になりやすい
    • スパースコミュニケーション(これありそう。特に仲が悪い場合。)
      • モックサーバーを作り認識齟齬を埋める
    • インフラレスポンシビリティ
      • そもそもBFFを誰がお守りするのか
      • A : 全員
    • ビッグバンジョイント
      • APIのリクエスト・レスポンスは想定通りじゃない
      • 確実に想定外の問題は起きる

15:00-15:40 Microservicesの始め方、あるいは始めるべきか

  • Microservicesによってスピード感を持つことが必要。
  • スタートアップはオーナーシップが必要なので、マイクロサービスが必要ない。
  • メルカリも100人こえてる辺りから、Microservicesを始めた。
  • 組織とシステムを分ける必要があるのか -> インフラエンジニアを持てないチームが出てきた場合の問題は？
  • 統一したチームでツールを作り、インフラを構築したりスケールできるようにする。Self Service Tool的な。
  • メルカリはMicroservicesでGCPを使っている。<- terraformです。

16:00-16:40 コンテナ業界の尖った人達による、技術から組織までのぶっちゃけトーク ~こわくない、こわくないよ~

  • 組織に問題があるから、それがMicroservicesで解決できるとは思わないほうがいい。
  • 特に大きくてサービスにとって重要なサービスを切り出す。
    • 切り出すきっかけ -> Codeベースが大きすぎて修正した時の影響範囲とか
  • 手を入れやすくするという面でMicroservicesはエンジニアにとっての福利厚生かもしれない。
  • ECSとKubernatis
    • KubernatisはVersion1でProduction Readyだった。
      • 複雑な要件がなくシンプルで導入できそう、APIが標準化されていた。
      • 少人数で運用だけで回したかったのでKubernatisを選んだ。
  • その時、その時の選択で決まる・・と。
    • メルカリKubernatisが99%・・。
      • 知見が溜まっているから初期コスト回避のためにもKubernatisを利用することが多い・・。
  • EKSが出てきた時にどうする的な話はあった。
    • ECSと比較して、コアコンポーネントの機能的には差はない。
    • 大きな差は周りのエコシステム。当時はモヒカンしか生き残れない世界からECSを使っていた的な。
    • 改めて見直しをしてもよいけど、積極的にECSから乗り換えるような議論にはなっていない。
  • AWSでこういうツールほしい的な話
    • FargateをEC2上でホスティングする何か？
    • EKSでWorkerノードもマネージドしてほしい的な。
    • EKSはアップデートが怖いので、その辺りをマネージサービスでカバーしてくれると嬉しい。
    • KubernatisのノードのCanalyアップデートがほしい的な。
  • KubernatisはインフラのRailsのようなもの・・！？
  • 今後のキャリアは？
    • -> スタートアップとか、自分のサービスとか
    • -> エンジニアとしてできることを増やしていくこと
    • -> 使う側じゃなくて作る側に回ってみたい
    • -> 会社が進むための技術力の見識や知識

参考サイト

所感

初めてAWS Loft Tokyoに行きました！

f:id:yasay:20181113081515j:plain
目黒セントラルビルの17階から見る眺めは素晴らしいの一言！
毎日こんな景観を見ながら仕事できるといいのになぁ。

Microservicesの憑き物が落ちた感じがした。

特に「マイクロサービス化デザインパターン」のセッションにて、
マイクロサービスがbuzzワードになっている現状と、具体的なマイクロサービスの
導入アプローチを知ることができたので、何か憑き物が落ち感があります。

既にAPIやキューを使った疎結合を実現しており
密結合はほぼ存在しないアーキテクチャが多い。
そういった状況からサービスメッシュを使ってハンドリングしやすくするのが
今のマイクロサービスアーキテクチャのトレンドであって、
マイクロサービスになっていないわけではない。
と言える気がするくらいには憑き物が落ちました。

結局一番大事なことは、事業として成り立っているかどうかだと思う。

その後にリファクタリングしていけばいいじゃん？的な。
スピード感はやっぱり大事だよね。

参加した皆様、お疲れ様でした！
以上です！

「Slackの未読に気付けるように実践したこと」＆「Slackテーマが超イケてる件について」

Slack テクニカルナレッジ

Slackの未読に気付けるように実践したこと

私は最近、岡山に本社がある企業様とSlackで連絡を取り合い仕事をしています。
その際に一度、メッセージを見逃してしまうということがありました。

Slackの公式ドキュメントで下記のナレッジがあり、
重要なメッセージを見逃さないようにする対策が紹介されています。

もう二度と、重要なメッセージを見逃さないために実践していることを下記に記します。

全ての未読メッセージを確認する設定を有効にする

この設定を有効にすることで、「全未読」というチャンネルのようなものが表示されます。
「全未読」がハイライトされている時はすぐに気付けるので便利です。
get.slack.help

通知の設定を変更する

通知のタイミング

すべての新規メッセージに変更する。


f:id:yasay:20181108123321p:plain

重要なキーワードをマイキーワードに登録する

自分の場合はリリースとかデプロイ依頼が来るので、マイキーワードとして設定しています。


f:id:yasay:20181011114022p:plain

デスクトップでアクティブでない時…

「非アクティブ状態になったらすぐに」を選択し、併せてメール通知を送信するようにする。


f:id:yasay:20181011114152p:plain

ステータスを設定する。

特定の時間帯に不在であったり、有給休暇を取得する時にステータスを設定しています。
他にも、スマホを家に忘れてきてモバイルから確認できない時などもステータスを設定しています。

↓の例では、時間指定をして業務中であることを明示してみました。


f:id:yasay:20181011121830p:plain

メッセージを読んだことをリアクションする。

これ、意外と重要だったりします。
SlackはLINEのように既読マークが付くわけではありません。
ビジネスでスピード感が求められる時にチャットベースで仕事する場合には、
メッセージを見たことを即座にリアクションすることが大事だと思いました。

その時に私が使っているリアクションが:eyes:です。


f:id:yasay:20181108124615p:plain
実は、私はSlackを使い始めてからしばらくの間、
この:eyes:が何を意味しているのか分かりませんでした。
「監視」？、「あとで見る」？、それとも、「把握しました」？
正解は「メッセージを見ました」ということなんだと思います。
Slack初心者の方は、リアクションの使い分け方を最初に学んだほうが良いと思います。

デメリット

デメリットもあります。それは、スマホの充電がみるみる減っていくことｗ
通知が多いチャンネルに参加している場合に、特に充電の減りが早い気がします。
こればっかりはしょうがない・・。

おまけ：Slackテーマが超イケてる件

おまけで、Slackテーマのお話です！
これさえあれば複数のSlackチャンネルを差別化できます！
GitHubで公開されてるので、forkすることもできます！

できればダークモードも実装してくださいマジお願いしますSlack様。

Slack Themes

f:id:yasay:20180613170724p:plain
Slack Themes
github.com

Material Slack Themes

f:id:yasay:20180613170927p:plain
Material Slack Themes
github.com

以上です！

Happy Hacking Keyboardを使い初めて3週間が経ちました！果たしてHappyなHackingが出来るようになったのか・・！？

ガジェットレビュー

実はHappy Hacking Keyboardを10月の初旬に
知り合いから安く売ってもらえる機会がありました。

f:id:yasay:20181011152057j:plain
Happy Hacking Keyboard | HHKB Professional JP | PFU

利用開始から3週間が経過し、使用感もまとまってきたのでエントリーを残します！

選択の動機

職場ではリアルフォースを使わせてもらっていて、
静電容量無接点方式キーボードの使い心地の良さをずっと体験していました。
個人的にも自宅で静電容量無接点方式キーボードを使いたいと思っていました。
そうなると、リアルフォースかHHKBくらいしか選択肢がありませんでした。
※最近出たNizというキーボードもありますが、できるだけ王道を行きたかった。

「エンジニアなら変化を恐れちゃだめでしょｗｗ」という内なる囁きを聞き、
新しいキーバインディングに慣れつつもMacとWindowsで兼用できる
静電容量無接点方式キーボードを使いたいなと思い、Happy Hacking Keyboardを選択しました！

Happy Hacking Keyboardを利用するために実践したこと

すぐに使う必要があるキーバインディングを覚える。

人によって使う頻度の多いキーは異なりますが、
私の場合は下記のキーバインディングを重点的に覚えました。

  • 「F1」～「F10」：「Fn」＋「0」～「９」
  • 「Home」：「Fn」＋「K」
  • 「End」：「Fn」＋「<」
  • 「Ins」：「Fn」＋「\」

今までのキーボードと明らかに異なる位置にあるキーを把握する

「HH」キー

Macの場合は「Caps」、WIndowsの場合は「半角／全角」となるHHキー
明らかに普段使うキーボードとは異なる配置の場所にありますので慣れが必要です。

「Control」キー

UNIX配列ですので「Control」キーの位置が普段使っていたキーボードと異なり、慣れが必要でした。
というか、こちらのほうがしっくりくるかも。打ちやすい。元々英語キーボードも使っていましたし。

購入してよかったこと

今まで使用頻度が低かったキーバインドを利用するようになった。

常時日本語入力モードにして、半角英数字を入力したい場合は「F10（Fn＋0）」を使うほうがしっくりきた。
また、半角スペースは「Shift」＋「Space」を使う頻度が多くなった。

キーの入力感度は最高。一度使うと他のには戻れないかも！

なんと表現すればよいのか悩むのですが、
HHKBの打ち心地は、高級な積み木を転がしているような感覚・・かもしれません。
打ち心地には心底惚れ込みました！

ここが辛いよHappy Hacking Keyboard

矢印キーに「Home」、「End」、「PgUp」、「PgDn」を割り当てられない。

（Windows PCを利用しているケースにおいて限定ですが）
Macの標準キーボードに使われているデフォルトなキーバインドと同じことが出来ないのは辛い。
Dip Switchで「Del」などに切り替えられなくていいので、「Home」などに切り替えられるようにしてほしい。
ソフトウェアで対応できないかなー？

しかしながら、HHKBのキーバインディングを真似た製品が多く出回っているので、
デファクトスタンダートの地位を築いているのかもしれない。・・つまり慣れるしかないんだろうなぁ。

「Ctrl」+「Alt」+「Delete」が押しにくい！

Windowsユーザなら使うであろう、「Ctrl」＋「Alt」＋「Delete」。
私はVirtula BoxのUbuntuに影響を与えないように、画面をロックする時に利用しています。
「Delete」が簡単に押せないんですねー。「Fn」キーと同時押しする必要があります。

慣れれば慣れるほど、標準的な配列のキーボードを利用した時に違和感を感じる。

できるだけ、どこでもHHKBを使ったほうがいいことになります。
持ち歩きたくないので2台持ちとかになると、お金がかさみますねー！
しかしながら、この押し心地には変えられない魅力がありますので、結局使ってしまう・・。

理想形はHHKBの二刀流！？

分割キーボードはまだ種類が少なく、
高価なものが多いので敷居が圧倒的に高いです。
安価で入手できるMistel Barocco600も検討しましたが、
マニュアルを読んでいるとキーバインディングが独特すぎて使いにくいそうな感じがしました。

しかしながら、分割キーボードによる肩こりの解消は見逃せません！

となると、理想形はHHKBの二刀流かもしれません！？
Type-Sを購入すればUSBハブが内蔵されていますので、
それを利用してもう1台のHHKBを接続するとか！？
いつか試してみたいなぁ・・。

総評

HappyなHackingができるように・・なりました！！
数十年、愛用していきたいキーボードです！

よく参照するページ

以上です！