amareloのブログ(仮)

IT系勉強会で感じた想いや知見をメインに書いていきます。

JAWS-UG朝会 #31 参加レポート

3/14 JAWS-UG朝会 #31 に参加しました。久々に参加レポートを書きます。

目次

イベントページ

jawsug-asa.connpass.com

セッション内容

セッション① Amazon Linux 2022をさわってみた 株式会社サーバーワークス 小倉大さん

Amazon Linux 2022とは

  • 現時点ではプレビュー版。
  • Amazon Linux 2 の後継バージョンOS(2023年6月30日で長期サポートが切れる)
  • 5年の長期サポート
    • 最初の2年はアクティブな開発フェーズ。後の3年はメンテナンスフェーズ。

Amazon Linux 2との違い

  • SSM Agentがデフォルトで入っていない
    • 手動インストールが必要
    • EC2作成時にインターネットへ疎通できるようにする必要がある。
      • S3へSSM Agentのパッケージを取りに行く。
      • セッションマネージャーでログインする時にSystems Managerへアクセスする。
  • SE Linux がデフォルトで有効
    • パッケージ管理がdnf
      • yum の後継コマンドでオプションは一緒
      • 今のところyumも使える。
      • Amazon Linux Extras が使えない。
  • SSH接続がデフォルトでRSA無効
    • キーペアタイプをED25519にする。
    • RSAで接続するには
      • sshd_configに追加
      • ターミナルにrsa_sha2_512を選択

新機能を確認するときのやり方

  • とりあえず手順をあまり見ないでマネコンを触り、詰まったら調べて対応する。
  • これの繰り返しをして、詰まったところを調べた方が覚えやすい。

資料

www.slideshare.net

セッション② インプレースデプロイからBlue/Greenデプロイへの変更をゴリ押しで進めた話 株式会社サーバーワークス 古川敏光さん

既存環境

  • 複数の環境がFargate上で稼働している。
  • Internal ALBによるサービス間通信。
  • ECSはローリングアップデート
  • EC2上にJenkinsを構築

BGデプロイ実装方法

  • ターゲットグループの直接切り替え
    • NLBの後段にInternalALBを設置
    • AWS CLIを使用してNLBのターゲットグループを直接切り替える。
    • 実装コストを第一優先に考えると望ましかった。

懸念点

  • サービス間のアクセスをどうするか?
    • ALBの後にNginxを配置してURLでリバースプロキシ先を切り替える。
    • Fargate上にNginxを構築して、各ECSコンテナに自動でAレコード登録をする。

ゴリ押しポイント

  • 既存テンプレートを使いたいので、ServerlessFrameworkを使う。
  • ターゲットグループ1つに対して、関連付けられるリスナールールは1つのみ。
    • ターゲットグループとリスナールールの関連付けを自ら行う必要がある。

まとめ

  • BGデプロイ手法に正解はない。
  • 実装コストやダウンタイム許容時間など、要件に沿ってデプロイ手法を決める。
  • Codeシリーズの方がCI/CDの実装コストは小さいが、Jenkinsの方が細かいジョブを設定できる。

資料

speakerdeck.com

LT① AssumePolicyの意外なハマりどころ 崎原晴香さん

今回実現したいこと

  • とあるAssumeRoleの権限移譲先として、あるグループに属しているIAMユーザ全員を指定したいケースを考える。
  • しかし、IAMユーザグループをAssumePolicyのプリンシパルに指定することはできない。

解決策

  • TerraformのDataSourceを利用
    • IAMグループに属するIAMユーザ情報をリスト形式で得ることができる。
    • 所属ユーザARN一覧をfor文で取り出してAssumePolicyのプリンシパルに指定することができる。
      • グループに新しくユーザが追加されても、追加ユーザのARNをプリンシパルに追加するところまで自動化することができる。

資料

speakerdeck.com

LT② DirectConnectGatewayの罠!? 株式会社ターン・アンド・フロンティア 坂下朱紀さん

DirectConnectGatewayとは

  • DirectConnectのAWS側の受け口の一つ
    • ない場合はVPCごとにVIFが必要。
      • ルータ設定が必要など
    • あると拡張性がある
      • VPCとの共有もできる。
      • ルータ設定も不要

構成変更で分かったこと

  • DirectConnectを冗長化してActive-Active構成にすると、戻りの通信が異なる経路になってしまう。
  • VGWは複数のDXGWに紐づけられない。
  • DirectConnectGatewayを使わずDirectConnectを冗長化した。

資料

www.slideshare.net

LT③ 漏洩しても大丈夫なクレデンシャル運用ができないか考えてみた 株式会社ゲームエイト 岩佐海彦さん

やらかし防衛策を並べてみたらIP制限したくなった

  • リーク先のリモートからではなく端末上で叩かれるのは防げない。

可変IP、複数IPでも使える基盤を考える

  • 未許可のIPからでも許可申請を受け付ける必要がある。
    • 踏み台IAMユーザを作る
    • 踏み台ユーザはMFA必須。かつキャッシュしないようにする。
  • 複数IPでも利用できるようにするには
    • 申請日時を管理して一定時間ずつIPを貯める。
      • DynamoDBにてTTL(Time To Live)管理をする。
        • TTL設定することで自然消滅してくれる。

IAMの権限を書き換える権限の注意

資料

speakerdeck.com

LT④ AZ間レイテンシを比較してみた 積田 優生さん

前提知識

  • リージョン
  • アベイラビリティゾーン(AZ)
    • 複数のデータセンタによって構成された耐障害性を意識した設計を採用
      • どのリージョンも2つ以上のAZで構成されている。
      • AZは1つ以上のDCから構成されている。
  • AZ名とAZ IDについて
    • AZ名は各AWSアカウント個別に割り当てられるため、AZ名とAZ IDの対応が違う場合がある。
    • データ転送量やレイテンシーの観点から、AWSアカウントをまたいで同一のAZを利用したい場合は、AZ IDにてAZの認識を合わせる必要がある。

レイテンシ(ラウンドトリップ)測定概要

  • 東京リージョンと大阪リージョンのAZ間レイテンシを測定
  • 各サブネットにEC2(m5.large)を1台ずつ作成

測定結果

  • 単一のAZのみを利用する場合、同一AZ内でレイテンシの差はどのAZでもほとんどない。
  • 大阪リージョンのAZ間レイテンシが想定以上に低かった。
    • AZ間でのレイテンシ要件が厳しい場合は、大阪リージョンを利用するのも1つのオプション

資料

speakerdeck.com

所見

リージョンとアベイラビリティゾーンについては意識しないと忘れることが多そうなので、今回の朝会で見直そうと思いました。

認証認可の管理方法も環境によってさまざまな実現方法があるんだと思い、奥の深さを感じることができました。

サービスや実装方法の深掘り、とりあえず触ってみることもあまりできていないので、もっと研究してみたくなりました。

最後に

2022年一発目の記事でした。年が明けてから勉強会に参加していたものの、ブログレポートは何か書く気が起きず…それ以外のネタも書けず…書こうと思っても書けませんでした。

最近勉強会に参加してても散漫になっていると思い、今日はブログ書く前提で参加しました。その意識があるだけで、発表の聞く集中力が全然違いました。今後もなるべくアウトプット前提で勉強会に参加していこうと思います。

ブログ休んでたのはちょっと思うところがあってなので、その辺は書けたら書こうと思います。

JAWS-UG 初心者支部#40 年忘れLT大会!! 参加レポート

はじめに

12/27 JAWS-UG 初心者支部#40 年忘れLT大会!!に参加し、登壇してきました。 まずは登壇者皆さんのお話のまとめをしてから、自分の登壇の振り返りをしたいと思います。

イベントページ

jawsug-bgnr.connpass.com

LTの内容

新プロダクト開発でやったこととやり残したこと 小室 貴史様

  • 実施したこと
    • 一人インフラエンジニアは大変なため、持続可能な環境構築を心がけた。
    • 運用の手間をいかに減らすかに注力した。
      • IaC、CDK、Fargate + ALB
  • できなかったこと
    • メトリクス分析、アナリティクス、機械学習はできなかった。

資料

speakerdeck.com

おいでよ!CLI専門支部 emi様

  • CLI専門支部とは

    • CLIを使いこなしたいユーザの集まりでハンズオンメインの活動
    • AWSとどう付き合っていくかを考えて行く場、特に本番環境
    • 別名転職専門支部
  • CLIを勉強すると何が嬉しいのか?

    • CLIを学ぶことでAWSサービスのAPIのほぼすべてを操作できるようになる。
    • APIを理解することでAWSを真に理解することにつながる。
    • 反復再現性が高いので、自動化にも対応しやすい。
  • CLI専門支部の楽しいところ

    • ハンズオン終了後アンケートでワイワイする感じが楽しい。
    • 波田野さんのほどよい鬼畜ワード
  • CLI専門支部への参加条件

    • CLI身に付けたい人ならば、誰でもOK!
    • LINUXの知識があった方が良い。

資料

speakerdeck.com

re:Invent 2021個人的に気になったアップデート 山口 正徳様

  • Well-Architected Framework に持続可能性の柱が追加された。
    • システムのあるべき姿を見つめなおす時が来た。
    • あなたのシステムは、本当にその規模のリソースを必要としているか?を考えなければならない。
    • あなたの顧客は、システムに対し本当にその性能を求めているか?を考えなければならない。
    • AWSを上手く利用することでだけでなく、Sustainabilityについて常にセットで考えなければいけない状況にある。
      • スケールアウトだけでなく、スケールインを実装する。
      • インスタンスタイプを一つ落とすだけでも電力量は変わる。
      • I/Oを求められていない場合は、磁気ディスクを採用する。
        • 磁気ディスクの方が電力量が低い
    • 持続可能性の柱は、簡単なところから適用できる。

資料

speakerdeck.com

aws.amazon.com

ラスベガスで感じたこと AWSJ Kameda様

  • re:Inventの会場はマスクをしていたが、アメリカの町ではしていない人が多かった。
  • アメリカは、コラテラルダメージ(副次的被害)の考えが大きい。
    • プラスの影響とマイナスの影響を合算した考えで行動しており、日本と違って合理性が強い。
  • 印象に残ったアップデート
    • AWS Mainframe Modernization
      • COBOLからJAVAの自動変換
        • ハンズオン環境を作るのにCOBOL環境作れる人いたら連絡ほしい。
    • AWS Migration Hub Refactor Spaces
      • モノリシックなアプリケーションをモダナイズ化させるために、アプリケーションをリファクタリングするための設計を保持するサービス。

ビギナーが、CloudFormationを使ってハマったお話 上地 航平様

  • IaCとは
    • インフラ環境をコードで管理する概念
  • CFnの利用
    • ローカル環境でテンプレートファイルを記述
    • CFnへデプロイ
    • 各種AWSサービスをスタックとして構築
  • テンプレートファイル間で、リソースの関連付けが重要
    • 2層目で記述したSGは、1層目で記述したVPCに所属する
  • エラー文はコンソールの方が見やすい。

資料

speakerdeck.com

AWSちょっと興味ある」人が技術コミュニティでエンジョイするには!?  御田 稔様

  • AWSが少しづつ分かってくるとコミュニティ参加が楽しくなる。
  • すぐ触れる環境があるのは恵まれている。手を動かそう!
  • 初心者向けのハンズオンをやってみよう。
  • アウトプットしろ!!
    • コミュニティ全体の心理的安全性が高まる。
    • 発言が活発になり、インプットがさらに増える。
    • 技術ブログを書いてみる。
    • LTに挑戦してみる
  • 知らないことは当たり前
    • 恥ずかしがっちゃダメ、別に死なないから!
    • 間違うことを恐れていたらアウトプットできない。
  • 技術コミュニティをエンジョイすると
    • 一気に視野が広がる
    • AWSスキルを楽しく伸ばせる
    • 市場価値が上がる

資料

speakerdeck.com

機械学習を教えてもらった事がない初心者がAmazon SageMaker Studio Labを触ってみた 長田 英幸様

  • Amazon SageMaker Studio Lab とは
    • AWSアカウントやクラウドの知識がなくても、誰でも機械学習を学んで実験できる無料サービス
    • 英語のドキュメントしかないが、ブラウザの翻訳機能を活用
    • ブラウザ上で作業が完結するのでとっつきやすい。

資料

speakerdeck.com

機械学習民主化が加速する!re:Invent 2021で発表されたノーコードで機械学習のモデルが作れるサービス、『Sagemaker Canvas』について Takashi Kawamoto様

  • SageMaker Canvasとは
    • ノーコードで機械学習のモデルを作れる新サービス
  • SageMakerとは?
    • Machine Learningサービス
    • たくさんファミリー機能がある
  • SageMaker Canvasの特徴
    • MLの専門知識がなくても使える新設設計
    • 専門用語を用いないように配慮されている
    • AWSコンソールを経由しないシングルサインオン
    • 前処理をあるていど自動的にやってそうだが、欠損値があるとエラーになる。

資料

speakerdeck.com

2021年のJAWS-UGの活動振り返り 沼口 繁様

  • CLI専門支部の勉強会申し込み者数が凄い!勉強会開催回数も一番多い!
  • 初心者支部は登録メンバ数がJAWS-UG支部の中で一番多い。
  • BIG DATA支部がこの1年で一番メンバー増加率が高かった。
  • 新しいことへの興味がわかないと、同じ興味を持つ人とのつながりが広がらない。
    • Self Running User Community の継続が難しくなる。
    • 地域支部の問題だけではない。

資料

www.slideshare.net

自分のLT 「MFAデバイスを無くした時の対応方法」

最後に自分のLTについて触れます。

先日、仮想デバイスとして使っていたiPhoneをMFAデバイス変更せずに機種変した話と、その時の対応方法について話しました。 厳密には「無くした」と思っておりこのタイトルにしましたが、よくよく考えたらタイトルと内容にはズレがあるのでは?と思いました。 タイトル通りMFAデバイス(ハードウェアトークン等)を紛失した時のことを期待していた方もいたかもしれません。 そう思うと、それを期待していた参加者の方々には申し訳ないことをしたと反省しています。

話す内容とタイトルに乖離を生じさせたり、参加者に誤解を与えないよう、以後気をつけなければと思いました。

資料

speakerdeck.com

最後に

思えば、今年最初の登壇が初心者支部での登壇でした。また登壇の機会をいただけて、初心者支部の皆様に感謝いたします。

まだまだ勉強不足ですし、初心者の域を脱していないと思っています。来年もAWSを通じて技術の深掘りをし、一つでも多くアウトプットできるよう励みたいと思いました。

寒くてもアイスコーヒーのすすめ

目次

はじめに

この記事は、Coffee Advent Carendar 2021 第5日目の記事です。

adventar.org

先週から急に寒くなってきましたが、いかがお過ごしでしょうか?

今日は、寒くてもアイスコーヒーを勧めたい!という、季節感まったくない記事を書きます。

寒くてもアイスコーヒーの理由

手軽にコーヒーを飲める

コロナ禍の在宅勤務で、休憩時間中にコーヒー豆を挽いて飲む方も増えたかと思います。 とはいえ、毎日コーヒー豆を挽くのも大変、豆を挽く時間がないという時もきっとあると思います。

そんな時は冷蔵庫にアイスコーヒーを入れておきましょう!!

忙しくても、冷蔵庫に行ってさっと取り出せて、グラスに注げばすぐにコーヒーを味わえるます。

最近、在宅勤務でコーヒーを飲む時間が取れない日も出てくるようになり、コーヒーを飲む時間の確保方法を色々考えていましたが、

アイスコーヒー作っておけば忙しくてもすぐ飲める!!!

と思い、寒くてもアイスコーヒーを作っておき、いつでも飲めるようにしました。これで、忙しくてもコーヒーを飲みたくなった時は、アイスコーヒーを注いで飲んで、すぐに仕事に取り掛かれます。

暖かい部屋で飲むと格別!!

寒くてもアイスコーヒーを飲むようになり、気づいたことです。

暖房器具を使うと部屋も乾燥するし、頭もボーっとすることが増えます。そんな暖かい部屋で冷たいアイスコーヒーを飲むと、シャキッとします! ホットコーヒーよりも喉が潤う感じもしますので、良いと思います。

暖かい部屋やコタツで飲むアイスコーヒーの時間は、至福の時です!!

電気代喰って家計を逼迫しない程度でやってみてくださいw

最後に

コーヒーを柔軟に飲めるようになって、在宅勤務できることに本当に感謝しています。その分、仕事のアウトプットの早さと質は上げなければなと思いました。その在宅勤務をきっかけに、改めてアイスコーヒーの手軽さとありがたさ、楽しみ方を再確認することができました。

今後は、アイスコーヒーとは年中付き合っていくことになりそうです!!

コーヒー豆の名前からコーヒーを選んでみよう

目次

はじめに

この記事は、Coffee Advent Carendar 2021 第1日目の記事です。

というわけで、今年もCoffee Advent Carendarがはじまりました。 初日は言い出しっぺの私amarelo(アマレロ)が書いていきます。

スペシャルティコーヒーには、生産国だけでも様々な豆が存在し、様々な味わいがあります。 たくさんあって迷う人もいらっしゃるかもしれません。そんなときは、好みの味の傾向と豆の名称で選んでみるのはいかがでしょうか? 今回は、これからコーヒーを豆で買って家で抽出してみたいという方向けに、おススメの豆を紹介します。 まずは、中煎りの豆から2つ、深煎りの豆から1つご紹介します。

中煎り(シティロースト)の豆

中煎りの豆では、私はブラジルの豆が大好きで、「おススメの豆は?」と聞かれたら一番最初に勧めるくらい大好きです。 ブラジルの豆は、苦味と酸味のバランスが良く、上手く焙煎できた時に感じる甘味が最高だと思っています。 なので、酸味がいいか苦味がいいか迷ったら、まずはブラジルの中煎り豆を選んでみてください。そこから自分の好みがどちらか見つけることができると思います。 コーヒー豆購入の一歩を踏み出しやすくしてくれる豆だと考えています。

また、甘さを感じさせるネーミングが多く馴染みやすいので、そこもおススメです。その中から2つ紹介します。

ブラジル さくらブルボン

過去にもこのブログで紹介したことがあります。

amarelo24.hatenablog.com

日本人の大半が好きであろう花「さくら」。日本人の心に寄り添うような豆で大好きです。 さわやかな酸味と軽めの苦味、すっきりとした甘味が特徴です。 私はこの豆を春になるとかならず焙煎します。生豆の出来が年によって微妙に異なるので、毎年違った味わいを見せます。 毎年3月ごろから出回りますので、次は3か月くらい後になりますが、今から焙煎するのが楽しみです!!

これから寒くなりますが、少しずつ温かくなって頃にお店で見つけたらぜひお試しください!! 桜の花をのんびりと眺めながら飲んでみるのも良いものですよ♪

ブラジル サントアントニオ プレミアムショコラ

ほどよい苦味と甘味が心地よい豆です。 「ショコラ」という名の通り、チョコレートのような風味を想像させてくれます。 さくらブルボンとは違って通年手に入りやすい豆なので、時期を問わず贈り物にもおススメの豆です。 チョコレートやケーキをお供に飲むのも良いと思います♪

usfoods.co.jp

ちなみに、同じブラジルの豆で似た名前の「クイーンショコラ」という豆を最近焙煎しました。 プレミアムショコラの写真がなかったので、参考までにクイーンショコラの焙煎後の写真を載せておきます。 プレミアムショコラも近い感じに仕上がり、こちらもほどよい苦味と甘味を感じました。 休日の午後のひと時に良さそうなネーミングなのも良いです。

f:id:amarelo-n24:20211201065750p:plain

深煎り(フレンチロースト)の豆

深煎りはコロンビアの豆がおススメです。 自分はコロンビアの豆は深煎りがベストと考えています。苦味の中に感じる甘味が大好きです。 たくさんあって選ぶの迷いましたが、最近焙煎した豆を紹介します。

コロンビア ウィラ グランスイート

苦味の中に上品な甘さを感じることができて、仕事の眠気覚まし、のんびりとした午後のコーヒータイム、どちらにもおススメできる豆です。 アイスコーヒーにしても、エスプレッソにしても美味しく仕上がります。

深煎りにするとこんな感じに仕上がります。苦味が強そうに見えますが、それでも甘味も十分に感じられます。 余談ですが、深煎りには洋菓子だけでなく、最中やどら焼きのような和菓子もよく合います。一度試してみてください!

f:id:amarelo-n24:20211201001948p:plain

最後に

他にも紹介したい豆はありますが、今回は3つで終わりにしておこうと思います。 また別の機会に3つほどピックアップして書こうかなと思います。

自分は「甘味」を感じさせてくれる言葉に強く惹かれる傾向が強いため、ここから入ることをおススメしましたが、 インパクトを感じる言葉の傾向、好みの味は人それぞれです。 「カッコいい」「かわいい」と感じた名前からコーヒー豆を選んでみても良いと思います。

まずは第一印象で感じた豆を買ってみて、いろいろな豆を試してみてくださいね♪

redmine.tokyo 第21回勉強会 参加レポート

11/27(土) 「redmine.tokyo 第21回勉強会」に参加しました。

もう自分の中では恒例となった半年に一度のredmine.tokyo の勉強会、今回も様々な事例、Redmineを使い推進していく心構えを学ぶことができました。

今回も参加レポートを書いていきます。

目次

イベントページ

redmine.tokyo

YouTube

www.youtube.com

講演・LT(前半)

講演1:RedMica 2.0 新機能解説資料 @g_maedaさん

  • テキスト形式のフィルタで複数キーワードによるAND検索
    • スペースで区切るとAND検索
    • ""で区切るとこれまで通り単純なテキスト検索になる。
    • SQLワイルドカード(%_)をフィルタで使えなくなった。
  • ファイルの説明欄がフィルタに指定できるようになった。
    • 説明欄の検索も可能になった。
  • チケットのデフォルトクエリ
    • チケット一覧で特定のカスタムクエリをデフォルトで適用できるようになった。
    • Redmine Default Custom Query プラグイン相当の機能
  • グループごとに二要素認証必須設定
  • admin権限がないユーザでもグループメンバが表示可能に。
  • CommonMark Markdown の試験的サポート
    • HTMLタグが使える。
    • テーブルのセル内で改行や結合など、複雑なテーブルを書けるようになった。
  • Mermaid.jsによる作図
    • RedMica UI Extension プラグインがMermaid.jsによる作図に対応。

資料

www.slideshare.net

LT:ある工場の Redmine 2021" @netazoneさん

  • 添付したPDFの表示が面倒。ダウンロードなしでプレビューしたい。

    • view customizeで「BigPicture.js」組み込み
      • 画面遷移発生無しにプレビューを表示。
  • 通知メールがうざい

  • UIが古い

    • Purple Mine2
      • 右ペインが左に
    • 有料テーマ
      • 1年更新40-60ドル程度
        • Boostmine
          • かなりいじってありスタイリッシュ
        • Zenmine
          • Boostmineと同じ会社が作成
          • 標準に近い感じ
        • Abacusmine
          • これも標準に近い
    • 評価
      • 見た目をモダン化するには十分
      • 細かい作り込みはやや甘い
      • バージョンアップ追随される
  • まとめ

    • Redmineはカスタムするともっといいぞ!

資料

www.slideshare.net

LT:Redmine に必要なのは Confluence?" 齋藤 誠 さん

  • Redmineはシンプル、Jiraは多機能で何でもできる感あるが、少々分かりにくい。
  • Jiraはスクラムもカンバンも対応、Redmineは各種プラグインで。
  • ドキュメント管理について、Redmineは文書のリンクとWiki、JiraはConfluence。

  • Confluence

    • 表を簡単に作れる。
    • パワポで出来ることは大体できる。
    • 設計をしている間はほとんどConfluenceを使っている。
    • 仕様の変更履歴を確認・追跡できる。
  • スクラムのチケット運用

    • スプリント入れた段階ですべて二週間後に終わらせる。
    • 締切は一つしかない。消化方法は個人で考える。
    • スプリントの遅れが明確
  • 最後に

    • Confluenceは便利
    • 10名までならばSaaS版が無料。
    • Redmineでチケット切ってConfluenceでまとめるのもあり。

LT:アンガーマネジメント on RedMica"資料" @ryouma_nagare さん

  • 自分のタイプを知る(反するものに怒りを感じる)
    • アンガーマネジメント診断で検索
  • すべきという価値観を捨てる
  • 6秒間がまんする
  • 怒りを記録する

  • 転職はアンガーマネジメントの結果

    • 会社に貢献すべきという価値観を捨てた
    • もしこのスカウトをacceptしたら?と考えた
  • Redmicaでアンガーマネジメント

    • 怒りのチケットを起票
    • 不要なフィールドがあるとイライラするので非表示
    • 怒りを記録するのに非常に適している。
    • チケットの書き方を意識するので、6秒間がまんする、もし●●だったらと考えると自然と守れる。
    • 会社のRedmineには入れない方がいい。
    • それでも怒りを抑えられなかったら「DeathNote」プロジェクト

資料

www.slideshare.net

LT:RedMica Bridgeの紹介"資料" Fukuda Keiko さん

  • RedMica Bridgeとは
    • WebベースのRedmica
    • Redmineを気軽に利用してもらえるように
    • Redmineを個人のタスク管理ツールに
      • チケット機能に絞る
  • 機能
    • プロジェクトごとのチケット一覧
    • チケット作成・編集・コメント追加
  • 利用方法
    • RedMicaのサイトからアカウントとRedmine APIキーを登録

パネルディスカッション <Redmineとわたしたち> 

パネラー:みけねこさん、Tomokoさん、Ryokoさん、Mikaさん

Redmineのすきなところ、いまいちなところ

すきなところ

  • 記録に残しやすい
  • 記録を残せると、自分が欲しい情報を振り返ることができる。
  • 次の業務への抜け漏れを防ぐことができる。
  • 権限管理をフレキシブルに出来る。
  • カスタマイズがおもしろい。

いまいちなところ

  • ITエンジニア以外は使いづらい
  • 説明文が作文になってしまう。
  • UIがイマイチ
  • チケット入力までの導線がわかりづらい。
  • 自由過ぎるがそれが難しい。

Redmine利用のハードル

  • 初心者のハードル、とっかかりをどうにかできないか。
    • 利用する人のことを考えて作らないとならない。
  • ワークフローを設計しないとRedmineは使えないのでは?
  • テンプレートを用意
    • ユーザに選択させない。
    • URLにパラメータ埋め込んでテンプレート表示させる。
  • トロール
  • Redmineを使う業務を決めてフロー図見せることで納得してもらう。
    • 情報の集約場所、過去の情報もわかる。

伴走者

  • 使いづらいところを管理者に伝えて改善してもらっている。
    • 日々の使いやすさと改善の声を上げる立場。
  • 利用者が伝えてくれる要望を実現しようとしている。
  • ユーザが必要としているものを精査する。
  • 使ってもらってなんぼ。どうやったら使ってもらえるかを考える。
    • 日々のことからも相談しやすい雰囲気を創る。
    • みんなが幸せになることを分かってもらえるように。

人を大事にする

  • 敵対せずに使うためにはどうすればよいか?
    • 何事においても、つながる先には人がいることを常に頭に入れること。
    • 相手が分かりやすいように書くことが、人を大事にすることにつながるのではないか。
    • Redmineは説明を豊かにすることができる。
    • 文章の書き方に気をつける。
    • ツールを使うことにとらわれ過ぎない。
    • みんなが幸せになることを伝え続ける。

柔軟性

  • 新しいもの、新しい情報を受け入れて、自分の頭を柔らかくすること。
  • 人と話すこと。
  • 詳しいということにあぐらをかかずに、様々な意見を取り入れる。
  • 否定から入らない。
  • 小さなことでも始められるところは、まずやってみる。
    • 小さな改善を繰り返していくことでいい方向に向かっていく。
      • 小さな失敗と改善を繰り返すことをしやすいのがRedmine

講演・LT(後半)

講演2:林業におけるRedmine活用 田畑さん

  • 課題

    • 工程の全容がつかみづらい。
    • 情報格差が激しい。
    • 知っている人に作業が集中する。
  • 具体的手法

    • 作業手順は社内Wiki
    • 作業状況確認はRedmine + GTT plugin
    • プロジェクト=現場
    • バージョン=設計監督
    • トラッカー=設計、実施、監査
  • 導入で大変だったこと

    • 起票ができない。
    • 知っている人の時間を確保
    • 仕事の羅列
      • 知っている人の暇がない。
  • きこりのジレンマからの脱却

    • トップダウンで実施
    • 作業が進まなくても組織が死なない安心ができる状況を作る
  • よかったこと

    • 手戻りが減り各担当者が主体的に活動
    • 知っている人知らない人の差が圧倒的に縮小
    • 作業量の平準化
    • 作業の見通しがつきやすくなった。
  • 今やっていること

    • 何をするにしてもまずはチケットを確認・記述
    • 書いていくと安心という雰囲気の醸成
    • 見える化や情報文字化の推進

資料

speakerdeck.com

LT:Redmineで徒労を減らす" @MadoWindahead さん

  • さくせんのための武器防具仲間魔法

    • 武器防具
      • ありたい姿にたどり着く
      • 自分たちを守っていく
    • 仲間
      • こういうやつらがいればうまくいく
    • 回復魔法・攻撃魔法
      • こういう結果が出るから、さらに利用しやすくなる。
  • 徒労を減らす(トヘロス)ために

    • 自分より弱い敵と出会わない。ある程度強くなる。
      • 対応できそうな・成長が見込み目そうなメンバを揃える。
      • 必要な技術、前提条件をWikiやニュースに埋め込む。
    • 無駄を減らす・効率化する
      • 事実の把握における負荷やコストを減らす
        • Redmineがあれば不要なもの
          • 日報、月報
          • トラブル報告
          • 「今何やってるのか」という質問
        • 事実の把握から先手を打つことも可能
          • 予定のチェックからミスを事前に防ぐ
  • 強い敵とはたたかう。

    • プロジェクトにおける重要な内容はちゃんとやる。
    • そうなってるプロジェクトはあまりない。

資料

docs.google.com

LT:Redmine(SHERPA)の通知をMatterMost(チャット)に連携 iwsk さん

  • Redmineの標準通知メール通知したのをチャットで伝える手間を何とかできない。

    • SHERPAのコマンド通知機能を使って、メールと一緒にチャットに通知する。
  • 工夫したところ

    • オオカミ少年防止のため、必要なプロジェクトの特定のステータスだった場合にチャット通知。

LT:Redmine屋から見たMS Planner" @akipii さん

  • Plannerとは

    • Office365に付いているToDo管理ツール
  • 管理者や担当者が期待すること

    • 管理者は進捗状況が見たい。
    • 担当者は、報告作業を簡単にしたい。
  • 問題発生

    • タスクの更新が面倒
      • チェックリスト項目が多くて更新が手間過ぎる
    • 予定のタスクが多すぎる
    • 日次・週次の実績がわからない。
  • 原因

    • チェックリストやバケットは、作業状況のステータス管理に向かない
  • Redmineならばどうする?

    • トラッカーごとにワークフロー管理
    • ステータスは作業状態ごとに作成する
    • 親子チケットに分割する
    • Excel報告については、クエリで管理する
  • 業務フローを事前に洗い出そう

    • どんなワークフローでどんなステータス管理をするのか?
  • 誰のためのタスク管理ツールなのか?
  • できる作業者にマイクロマネジメント不要。

資料

www.slideshare.net

LT:Unofficial Redmine Cookingと直近のRedmineカスタマイズ事例の紹介" @y503unavailable さん

資料

speakerdeck.com

LT:Redmine パッチ会やってます! @juno_nishizaki さん

  • パッチ会に参加して良かったこと。

    • 参加しているうちにできることが増えていった。
    • できることが増えると嬉しい!
    • 大事なのは、やってみようという気持ち。
  • みなさんもいかがですか?

    • プログラミングのことがわからなくてもRedmineの改善に思いがあれば楽しめるはず。
    • オープンソースの開発に興味があるだけでもおススメ!
  • 次回のRedmineパッチ会

redmine-patch.connpass.com

資料

docs.google.com

LT:Redmine Japan Vol.2 開催します" @agilekawabata さん

  • 2022年2月25日(金)開催決定!
  • 「明日の仕事を変えるために必要なモノ」

感想

Redmineは良いものだけど、使う人のこと、組織のことを十分に考えて導入や推進するものだ」と改めて思いました。

自分の職場での進捗管理などはExcel管理なのですが、redmine.tokyoに参加して良い事例を学ぶことで、 自分の職場にも導入できないかとずっと思っていました。 これまでredmine.tokyoには何度も参加してきましたが、実は現時点でもほぼ未経験状態です。憧れの人をずっと遠くから見ているような気持ちで参加していました。

今年ようやくRedmineの導入を自分が進めることができるようになったものの、なかなか良さが伝わらずにいました。 さらに悶々としていたところで、今回の勉強会に参加して目が覚めました。 自分のために導入するのではなく、チームや会社の業務効率化、課題解決に使うものなのだから、足を引っ張ることになっては意味がない。 もう一度、

  • 目的(何のためのRedmineなのか)
  • 導入してどうしたいのか?どうありたいのか?
  • 関係者に手間をかけてしまうところは何か?

を見直し、関係者と共有するところからやり直そうと思いました。 結果的に導入を断念、失敗に終わるかもしれませんが、明日から改めてチャレンジしたいと思いました。 都合でディスカッションと懇親会には参加できませんでしたが、今回も多くの気づきと学びをいただけました。

一方、個人的にはRedmineを使って、コーヒーの焙煎記録を残せないかなどのチャレンジもしています。 そちらは完全に自分のためだけですが、将来的に誰かに見せる場合のこと、使いやすさ見やすさを考えて実現できればなぁと考えています。 Pranioで実現しようとしていましたが、いろいろカスタマイズした方が良さそうな気がして、サーバ建ててそちらでやろうかと思ってます。

感想長くなりましたが、先週までの仕事のモヤモヤが晴れた気がしました。 次回以降のどこかで実現できたことを登壇で発表できるよう、明日からも頑張ろうと思います!!

今回もありがとうございました!!!

JAWS-UG朝会 #27 参加レポート

11/8 JAWS-UG朝会 #27 に参加しましたので、レポートを書きます。

目次

イベントページ

jawsug-asa.connpass.com

登壇内容

セッション① ノンプログラマーAmazon Honeycodeでアプリを作ってみた emiさん

資料

speakerdeck.com

HoneyCodyとは

  • ノーコードアプリケーション開発できるフルマネージドサービス
    • 現時点でベータ版
  • AWSアカウントとは別にHoneyCodeアカウントを作成する必要がある。
    • メールアドレスのみ。クレカは不要。

HoneyCode主要概念

  • Table
    • 構造型データストア
  • builder
  • Automations
    • Tableのデータに対する変更やアプリ上の操作を起点に処理を実行
  • Workbook
    • 上記3つを包括する枠組み
    • 開発者や利用者に対し、Workbookやアプリケーションに権限付与

AWS認定取得状況アプリを作ってみた

  • 取得認定資格の選択
  • 新しい認定資格の追加

外部連携と制約

  • APIをたたいてTableデータのCreate,Read,Update,Deleteができる
  • 利用可能なリージョンが、オレゴンのみ。
  • AWS SSO連携する場合はオレゴンリージョンでセットアップが必要

まとめ

  • BuilderからGUIアプリを作成するのは結構大変
  • 目的に近いサンプルからアプリを展開してmodifyしていくのが良さそう
  • 日本語の情報がまだ少ない
  • 内部利用でアプリ作成するには良さそう

セッション② (仮)マルチアカウントでhealth情報を集約した 富松 広太さん

AWSからのメール

  • 24時間以内に対応するよう依頼が来た
  • Abuse(不正利用関連)の通知があるらしい
  • 緊急度の高いものはpush的に通知したく、AWS Healthを利用した。

AWS Health

  • Personal Health DashbordでAWSからの通知を確認できる。
  • Health + Organizationで全アカウントのHealthイベントを一括取得
    • Health APIを定期実行
    • 子アカウントでリソースを作成しなくて良い
    • 発生時間を指定してイベント取得を可能
  • Health + Organization API
    • 全eventを取得
    • eventに関するAWS AccountやAWS Resourceを取得

Tipsと失敗から学んだこと

  • 通知分類はリージョンとEventTypeCodeで考えると便利
  • 緊急度を2段階で分けると便利
    • メンテナンス系はチケット発行
    • Abuse系は人間に即時通知
  • 緊急度を高めておくと良さそうなEventTypeCode
    • AWS_ABUSE_XXXX:不正利用関連
    • AWS_CLOUDWATCH_XXXX:監視の機能不全
    • AWS_SES_XXXX:SES止める予告関連
    • 緊急のNWメンテ
    • AWSサービス名OPERATIONAL_ISSUE:サービス障害
  • Statusでフィルタしない方が良い
  • Ticket管理システムと連携する時

LT① QuickSIghtでCUR分析 アイディーエス 小寺 加奈子さん

AWSのコストと使用状況レポート(CUR)とは

  • コストと使用状況を包括的なデータとして確認できるレポート
    • 月次、日次、毎時間のレポートをS3に出力可能

可視化するには

  • Cost & Usage Report からS3バケットを出力設定
  • QuickSightのデータソースとしてS3を選択

可視化されると便利なこと

  • EC2インスタンスが何に使われていたのか
  • どのサービスにどのくらい課金されているか
  • 過去のデータとの比較ができるようになる
  • リソース変更時などのコストの確認が簡単になる

まとめ

  • コストと使用状況レポートを可視化できる。
  • CURレポートは請求金額が確定するまで日々の利用状況の積み重ねをすべてバージョン管理してS3に保管する。
    • 最新のレポートは、S3に出力される「マニフェストファイル」から確認する。
  • レポート更新は1日3回でリアルタイムではない。
    • QuickSightのデータセット取り込みもスケジュール化しておく。

LT② Control TowerとSIEM on OSSであっちこっちした件 小林 未来さん

資料

www.slideshare.net

すべてのはじまり

  • AWS上のログを追っていくのは大変だけど、セキュリティとは向き合いたい。
    • まとめて直感的に見れるよう、SIEM on OSS

SIEM on OSSとは

  • AWSオープンソースで公開している脅威検知の可視化ツール
  • LambdaでETL処理をしてCloudTrailのログを可視化してくれる

あっちこっちした流れ

  • 最初はシングルアカウントで構成したが、後々マルチアカウント構成に変更
  • Control Tower構成
  • 通知系はSecurityアカウントに集約
    • LogArchiveとの使い分け
      • 役割を決めなおした
  • マルチアカウント環境でのログ集約には高度なデプロイが必要
    • 事前にReadmeを読んでおくこと

まとめ

  • アカウント設計はちゃんとする
  • 手順書やReadmeはちゃんと読む
  • SIEM on OSSはおすすめ

LT③ AWS SSOでもアカウントエイリアスを表示したい!に応えるChrome拡張を作りました 小笠原 寛明さん

資料

docs.google.com

  • AWS SSOで生成されたアカウント名が画面に表示されない(最大61文字)
  • AWS SSOってスイッチロールみたいに色が変わるわけじゃない。
  • 既存chrome拡張だと設定が柔軟でなく、色の設定方法に不満があるため自作を決意した。

最後に

気になるサービス、不便に思うことは、触ってみたり作ってみたりを柔軟に考えたいと思わせられた朝会でした。不便に慣れるより、学んで得たことを活用して改善する。SOAの勉強をしながらいろいろ触って考えてみようと思いました。

来月か再来月にまた登壇したいなぁ。

JAWS-UG朝会 #26 参加レポート

10/28 JAWS-UG朝会 #26 に参加しました。 昨日、#27が行われましたが、#26のレポートを書いておいて公開していませんでした(汗) 今更ですいませんが、公開します。

目次

イベントページ

jawsug-asa.connpass.com

セッション① AWSソリューションのCFnで学ぶNaC NTTデータ 山本 泰士さん

  • TransitVPCとは?

    • 中継デバイスを経由し、VPCやオンプレミス間を中継するHubネットワーク
    • SpokeVPCのVGWにタグを追加するだけで、自動的にTransitVPC~SpokeVPC間のIPsecトンネルを確立・接続する。
      • 手動作業はVGWに特定のタグを付与するところのみ。
    • TransitGatewayやAutoScalingなどのサービスを組み合わせたり、vSRXやFortiGate、CISCO以外の機器を組み合わせることもできる。
      • AutoScalingと組み合わせた場合は、トラフィックに応じてSCR自動増減。スケーラビリティ向上。
  • TransitVPCのCloudFormation

    • Parametersセクション
      • スタック作成時に自由にパラメータ設定可能(デフォルト値もある)
        • 既存スタック・リソースのパラメータとの重複などは十分なケアが必要。
    • Resourceセクション
  • カスタムリソースとは?

    • 所定の書式でリソースを定義することで、関連付けられたLambdaを呼び出し、自由度の高いロジックを実装することが可能。
      • 呼び出し先はLambda、SNSも可能
  • TransitVPCのカスタムリソース

    • S3イベント作成の流れ(CloudFormationでタイプ指定できない例)
      • S3バケットにパラメータが格納されたことをトリガとしてLambda送信するように、S3にイベント通知を設定
    • RSAキー作成の流れ(CloudFormationテンプレートだけで実装できない一例)
      • 秘密鍵・公開鍵・フィンガープリントを生成・格納・設定し、Configurator関数がCSR1000vにアクセスできるよう設定
  • コード理解の不足による失敗談

    • 意図しないTransitVPC~SpokeVPC間の接続
      • 別のTransitVPCと同じタグを設定し、別のTransitVPC~SpokeVPC間で接続した。
    • AMI ID差異によるプロビジョニング失敗
      • MarketPlace内のAMIは更新していたが、CloudFormationテンプレートが更新されておらず、本番環境でプロビジョニング失敗した。
  • まとめ

    • CloudFormationとLambdaの組み合わせで詳細な設定が可能
    • なんでもかんでもLambdaに書くと可読性と保守性の良さが無くなる。
      • CFnとLambdaのバランスが重要
    • CFnとLambdaの内容を理解することで、有事の際の対応が楽になる。

セッション② AWS IoTのスゴいところご紹介 アイレット株式会社 本間 崇平さん

AWS IoT について

  • AWS IoTの仕組み

    • モノとなるデバイスへ制御を伝送したり、物の情報(テレメトリー)をAWS IoTを経由してアプリへ伝送することが可能となる。
  • AWS IoT Coreについて

    • インターネットに接続されたデバイスから、クラウドアプリケーションやその他のデバイスに簡単かつ安全に通信するためのマネージド型クラウドサービス
    • 数十億個のデバイスと数兆のメッセージをサポートしている。
  • バイス通信プロトコルメッセージブローカー

    • MQTT
      • 制約のあるデバイスように設計され、軽量で広く採用されているメッセージングプロトコル
    • MQTT over WSS
    • HTTPS
    • LoRaWAN
  • メッセージブローカー

  • モノの管理

    • IoTの物とは、クラウド内部の物理デバイスの表現と記録
    • 物理デバイスAWS IoTと連携するには、物の記録が必要
      • 物の名前をMQTTクライアントIDとして使用することがAWSで推奨されている。

AWS IoT のすごいところ

  • 証明書とポリシ

    • ポリシを作成して認可アクションのセットを定義できる。
    • 一つ以上のリソースのアクションを承認可能
  • ルールアクション

    • ルールがトリガされた時に動作を指定する。
    • 機能に応じて最適なリソースを選択できる
    • ログ保存と出力
  • FleetProvisioning

    • 動的に証明書払い出して解決してくれる。
  • DeviceShadow

    • 電源状態をシャドウに保存していれば、シャドウ参照で電源ONOFFが分かる。

まとめ

  • IoTのサービスは豊富にあるためすべて網羅はできていない
  • 要件次第ではIoTのマネージメントサービスを上手く活用することがベストプラクティスな手法となる。

LT① 辛くない CloudFormation 株式会社モリサワ 小室 貴史さん

資料

speakerdeck.com

辛いCloudFormation

  • 巨大なテンプレートで読むのが大変
    • ちょっとした変更のデプロイが困難
  • そのまま投入できない物
    • 初回のみ音対応が必要でコメントアウトとか
    • テンプレート内にリソースが追加されて依存関係が発生
      • CFn内では並行してリソースが作成される。
  • クロススタック参照の多用
    • 参照元のスタックの削除変更ができなくなって運用時に困る。

辛くないCloudFormation

  • 程よい大きさのテンプレートにする。
    • リソースのライフサイクルで分ける。
  • スタック作成順は残す。
    • クロススタック参照で困らないようにする。
    • Gitにテンプレとともに保存する。
  • すべてをCFnでムリにやらない。CLIも活用する。

LT② Quick Sight Qを使ってみよう アイディーエス 小寺 加奈子さん

  • QuickSight Qとは?
    • 機械学習を利用した自然言語クエリ機能
    • 利用にはEnterPriseエディションの利用が必要
    • 現時点では日本のリージョンでは未サポート

自分のLT

speakerdeck.com

資料にも書いて発表時にも話しましたが、ハンズオンは可能な限りGUICLI両方でやった方がいいなぁと改めて思いました。 これまでもCLI専門支部で感じてきたことですが、様々なハンズオンをやるたびに気づきやつまずきがたくさんあって、 何度も何度も思い知らされます!

最後に

自分の登壇の時に画面共有に手間取ってしまったのは痛恨の極みです。。。 3か月ぶりの登壇で少し緊張していたり、新しいモニターを買ってから初めての登壇だった・・・など、色々重なっていたと思います。 でも言い訳ですね(汗)環境変更後は余裕を持った行動をしないとなと思いました。