2019/5/24の金曜日に以下の勉強会に参加してきましたので記事にしていきます。
全体で80名くらいは参加者がいたのではないでしょうか。フューチャーアーキテクト株式会社さんの会議室で開催でした。
とてもきれいなオフィスで羨ましいと感じました。
発表内容のまとめ
勉強会の恒例ですが、発表内容の簡単なまとめ（メモ）を以下に記載します。
取り漏れも多少あり、間違えてメモしている個所もある可能性があるので、その場合は指摘していただければ適宜修正します。
マイクロサービス開発におけるドキュメンテーションサイクルへの問題定義：@HarunnobuKameda
AWSの中の人
AWSではメカニズムという考え方を重視している
サーバ、ストレージ等すべてAPIで操作できる
定常的に作業ができるようAPI化している
AWSの自動化はAPIの文書化とそれについての責任を持つ
ユーザはそのAPIを叩いて操作を行う
定義ファイルを書いていれば誰が何回やっても同じ結果が出る
AWSのサービスは165を超えている
CTOの立場だと不安がることが多い
マイクロサービスアーキテクチャ
一つのアプリケーションには一つの動作しかさせないようにする
AWSはRESTで統一する
OSやミドルウェアに依存しないように
HTTPSのAPIで連携
基本はAPIはステートレスで作成する
データベースはアップデートに関わらず動くように設計する必要がある
マイクロサービスとAPIの関係
疎結合なAPI連携のみで有機的に結合
APIへの改修、新規APIのリリースは最大限の注意が必要
APIの挙動が変わる際はドキュメンテーションとレビューをしなくては行けない
ウォータフォール型の方が相性がいいのでは？
マイクロサービスとアジャイル開発は相性が悪そうだけど・・・
・Side-car proxy
PorxyがAPIの通信を一括管理する。
App Mesh
所感
AWSは流石だなと６、組織のトップ層がしっかりと技術に対して真剣なんだなと感じます。
日本企業も最近は経営層が技術に関与するところが増えてきた気がしますが、やはりまだまだ頑張っていかないとなと。
ただ、やはりAWS内でも業務の効率化ができていないところがあったなど、以外な面もあるのだと思った。
でもそこを現状のままにせず改革できるところが素晴らしいなと。
技術書を翻訳してみたので、経験を共有してみる：石川さん
資格マニア、持っている資格めっちゃすごい！
「インテリジェンス駆動型インシデントレスポンス」を翻訳した
米国にいたときに翻訳した方がいいなという本が複数あった。
複数の出版社へ依頼出したが断られた。（かなり丁寧に）
O社はオッケーだった。
それで訳すことになった。運もある。
・事務手続き
企画書の提出・トライアル翻訳・契約
・翻訳の三種の神器
Word+Internet：非常に大事！
・折れない心が必須！
結構病む
・あとは必死に翻訳＋校閲
スケジュールは結構ずれるので注意
日本語って難しい
表記合わせ
コンピューターとコンピュータ
インシデント対応とインシデントレスポンス
新しい概念を翻訳に与える
翻訳者が本当に言いたいことを日本語で表現するのが難しい
やってよかったか
トピックへの深い理解
パーソナルブランディング
新しい知見・考え方の発信
まずは公開ドキュメントの翻訳をやるのがオススメ
著作権は気を付けよう！
所感
英語の書籍の翻訳って、やはり大変そうだなと。
しかしそれ以上にやりがいもあるのだなと。
英語力だけではなく、その本に書いてある技術は書いた人並みにつきそうですね。
isacaで毎月でているジャーナルとかも訳したら面白そうかも。
でもブログに記載したら、普通はログイン後にしか読めないから物凄い怒られそう。
要約を公開するくらいはいいのだろうか？
お知らせ。：@kotakanbeさん、@adachi0817さん
vuls祭りをやるのでその宣伝：日程は6/17にやる。会場はDMM。
trivy：vlusにコンテナスキャンを組み込もうとした副産物
検知率が高い
trivyは「コンテナ向けの脆弱性検知ツール」とのこと
trivyで検索するとブログがある。以下のどちらかでしょうか。
vlusがwordPressに対応した。簡単なコマンドでスキャンが可能
オープンソースの更新も盛んにやっている
IPAでテクニカルレポートも出ている。IPAオススメ
vlus.biz
一台無料キャンペーンもやっている
所感
vulsは検証したいな～と思っているんですが、まだできていない。。。
WordPressに対応したとのことなので、ローカルのVMに入っているのに入れてみようかしら。
もちろんやった際はブログの記事にしまっせ！
勉強会でこういったモチベーションをあげれることも色々な勉強会に参加することに利点ですね。
「運用自動化の基本原則」その2：@tcshさん
1.運用業務の構造化
なぜ迷走するか
運用業務が構造化されていない
①.人が理解しやすいようになっていない
②.システムが取り扱いやすいようになっていない
③.論理的に正しいことを検証できるようなっていない
構造化するためにはその逆をやる
運用業務の構造化はトップダウンからが重要
その後運用からボトムアップされるのが理想的である
実情はトップダウンもなく、運用はどうしたらいいかがわからないことが多い
2.運用自動化の基本原則その１
運用とはサービスデリバリを自動化すること
事業継続性向上に貢献
サービス価値向上に貢献
デリバリ価値向上に貢献
上記3つの視点が必要
運用自動化するのであれば運用に貢献しないといけない！
設計・実装者以外に引き継ぐことを前提に行わなければいけない
2.運用自動化の基本原則その２
平易化の原則
基本は平易化した業務に対してのみ行う。
平易：英語だとplainにイメージが近い
運用自動化の課題
難しく、複雑なものに対してやるのか
簡単で誰にでもできるものに対してやるのか
自動化する前に廃止する業務が無いかを確認してそれを廃止する。（重要）
UNIXの考え方が重要
複雑なものは人へ
簡単（平易）なものを自動化を
過去に発表した資料も含めいかにまとめてあるとのこと。
所感
私が数年前にssmjpに参加していたころから勢力的に発表していた方です。
確かに自動化はかなり色々なところに使おうと考えている人は多いですが、ちゃんと使い方を考えないと、逆効果になってしまうこともあるかもしれません。
また、やはりちゃんと経営層側が舵を切っていかないといけないのはマジでその通りだと思っています。
最後に
久々にssmjpに参加しましたが非常に面白かったですし、モチベーションを高めることができたので良かったです。
終了後の懇親会も参加するか少し悩みましたが、家庭の事情で今回は参加しませんでした。
次の機会の際には参加したいな～と思っています。
vlusは最近これで運用をしていこうと考えている組織も増えてきたので、私自身も触れるようになっていかないとな～
色々やることがありますが、頑張ります！
コメント