2020-03-14

ThinkCentre M75q-1 Tiny はコスパ抜群の小型PC

Lenovoの小型PC「ThinkCentre M75q-1 Tiny」を購入しました。
性能と価格のバランスが優れており、コスパを重視したいときにおすすめです。

実家用PCを探していたけど、ThinkCentre M75q-1に落ち着いた。 https://t.co/oWWmyfTLlv

週末価格＆不要なオプションを削ると……
・Ryzen 5 Pro 3400GE
・RAM 8GB
・M2 SSD 128GB
・USB Type-C x1
・USB Type-A x5
・HDMI
・DisplayPort
・Windows 10 Home
の構成が ¥32,120 で実現する。お安い
— yuu26/えむおん (@m_on_yu) 2020年3月1日

ThinkCentre M75q-1 Tinyの概要

Lenovoから発売されている小型PCです。

コストパフォーマンスの高さが注目されており、Ryzen 5 Pro＋RAM 8GB＋SSD 128GB＋充実したポートの構成が3万円代前半で購入できます。（週末価格＋クーポン適用）

ThinkCentre M75q-1 Tinyはコスパ抜群の小型PC

購入した背景

実家用PCとしての購入です。

「PC起動後1分くらいで電源が落ちてしまう」との連絡があり、色々試した結果どうも電源ユニットが怪しそう。購入から6年以上経過したこともあり、買い換える方向で次の機種を探すことにしました。

PCに求める要件

動画や写真の保存・YouTube・ネットサーフィンなどのライトな用途がメインのため、スペックはそこまで必要なし。（ネットサーフィンって死語？）

ということで、ざっくり決めた条件は以下の通り。

Core i3 相当以上
RAM 8GB以上
SSDは小容量でよい
Windows 10
性能よりもコスパ重視
モニタ・マウス・キーボードは不要
小型だと嬉しい

元々デスクトップを置いてあるので、モニタやマウスなどの周辺機器は流用できます。ただし本体はミドルタワーを使っていたため、小さな筐体へ変えたいとの思いもありました。

さらに求めるとすれば、（写真や動画が600GBほどあるので）データ用ドライブが内蔵できるとさらに良し、といったところです。

ThinkCentre M75q-1 Tiny が良さそう

昔と違って最新情報を追ってはいないので、まずはトレンドからざっくり確認。コスパ重視のときには価格.com もかなり参考になります。

調べてみたところ、Lenovoの「ThinkCentre M75q-1 Tiny」が中々良さそう。以下のスペックが 税込32,120円 で買えるらしい。

Ryzen 5 Pro 3400GE (3.3GHz)
RAM 8GB
NVMe SSD 128GB
USB-A 5ポート
USB-C 1ポート
HDMI
DisplayPort
LANポート

実際には次のオプションを追加して 税込37,620円 でした。

Wi-Fi（Wireless-AC 9260 + Bluetooth）
VESAマウントキット

今は実家にもWi-Fiがある＆LANケーブルもそろそろ怪しい雰囲気なので、無線へ変えることに。せっかく小型になったのでモニタ裏へ取り付けるVESAマウントも。

キャッシュレス決済の20%還元を始めとする各種キャンペーンに乗じて、最終的に24%還元（実質28,000円ほど）で購入。

今後拡張できる余地がある

ケースの中には2.5インチドライブの内蔵スペースがあるため、写真や動画用のストレージとして追加SSDを載せることが可能。

メモリ構成も自由に選べるため、8GBx1枚の構成を選択しました。仮に足りないとなった場合でも、空きスロットに8GBを足せば16GBに拡張できます。ありがたい。

（余談）HDMIかDisplay Portをオプション追加できるので、標準搭載の2ポートと合わせてトリプルディスプレイまで対応できます。

安く買う方法

ThinkCentre M75q-1 Tinyを安く買うためには少々コツが要ります。不要なオプションをすべて外す＆週末に買うのがベストです。

ベースとなるのは「価格.com限定パフォーマンスモデル」です。

ThinkCentre M75q-1 Tinyを安く買う方法

初期状態だと5万円ほどの価格ですが、以下の変更を加えることで 税込32,120円 が実現します。週末の方が安くなるらしく、平日に買うと3,000円ほど高くなります。

M.2 ストレージ・カードを 128GB に
キーボードを なし に
マウスを なし に
バーティカルスタンドを なし に
ツールレス (オープンシャーシ) を なし に

自宅でセットアップ

真新しいPCを実家に送ってもセットアップできる人がいないため、まずは自宅で受け取り。Amazonのように無駄に大きな箱で届きました。

実物を見てみると、本当にコンパクトな割にインタフェースが充実していて凄いですね。これが3万円台で買えるとは本当に良い時代。

ThinkCentre M75q-1 Tiny の前面

ThinkCentre M75q-1 Tiny の背面

背面の出っ張りはWi-Fiアンテナ端子です。付属の外部アンテナを取り付けて使います。

Windowsの初期設定、不要なアプリの削除、諸々のアップデート、ブラウザ（Chrome）の初期設定、などなどを済ませて完了。

オンラインでセットアップするとMicrosoftアカウントを強制されるため、ローカルアカウントで運用したい場合はオフラインで初期設定を済ませるのがコツです。

M75q-1 Tiny を開けてみる

将来的に2.5インチSSDを内蔵させる計画があるので、今のうちに中を開けてみます。背面にあるプラスネジを1つ外すだけの簡単構造。

表面には2.5インチドライブ用のスペースがあります。ケーブルも接続済みなので、デバイスだけ調達すればそのまま取り付けできそう。

ThinkCentre M75q-1 Tiny の内部

裏面にはNVMe SSDとRAMの取り付けスペース。NVMeはWestern Digital製の「PC SN520 NVMe SSD」、メモリはMicron製の「MTA8ATF1G64HZ」が搭載されていました。

ThinkCentre M75q-1 Tiny の内部

想定通りにメモリスロットの空きも確認できたので、後は閉じて実家に送るだけです。

既存デスクトップPCからのケーブル繋ぎ変えだけがネックですが、今はLINEやFaceTimeのビデオ通話でサポートできるので何とかなるでしょう。

ThinkCentre M75q-1 Tinyのまとめ

コスパ良好な小型デスクトップPC
インタフェースや購入後の拡張性も良好
最安値で買うにはオプション解除＆週末価格で
Ryzen 5 Pro＋RAM 8GB＋NVMe 128GBが3万円
実家のPCやサブマシンなどにおすすめ

2020-01-26

SRE NEXT 2020 へ参加してきた #srenext

SREのカンファレンス「SRE NEXT 2020」に参加してきました。学びが多かったので忘れないうちにメモしておきます。

参加したセッション

参加したセッションのメモをベタ書き。スライドが公開されているセッションであれば、スライドのリンクも貼っておきます。

なお、発表資料はさっそくQiitaにまとめている方がいました。ありがたい。 qiita.com

40000コンテナを動かすSREチームに至るまでの道

techblog.yahoo.co.jp

ヤフー社内のエンジニア向けに提供しているPaaS基盤
本番環境として40,000コンテナ以上稼働している
アラート対応は「利用者に影響があるか」を重視している
- 仮にメモリ使用量が増加してもユーザ影響がなければ急ぎの対応は不要
各アプリの稼働率が見えるSLOダッシュボードを用意
- 「ユーザ影響の有無」が分かるテストツールを作っている
- ブラックボックステストを数分間隔で各サービスに実行
SLO駆動でアラート対応、SREチーム内の評価指標にもSLOを使う
SREメンバ育成には障害対応のロールプレイを実施している
クラスタが複数落ちた→何のコマンドを打つ？誰に連絡する？など
マネージャ主導ではなく自己管理型のチームを目指している

大規模なPaaS基盤を運用しているSREチームのお話。数あるVMのメトリクス異常だけで通知を飛ばしているとキリがないので、「ユーザ影響のある事象に限り急いで通知→対応する」という方針は良いなと感じました。

パフォーマンスを最大化するためのSREのオンボーディング事例

speakerdeck.com

SREオンボーディングのゴール「オンコール対応ができる状態」とした
オンコール担当に求められる項目は大きく3つ
- 技術知識: メトリクスやログを調査できる
- ドメイン知識: サービスの機能やお客様への影響度が分かる
- コミュニケーション: 機能担当者の把握、SRE外と連携しての対応
ドメイン知識やコミュニケーションの習得が課題になりがち
ペアオペレーションとしてオンコール当番の対応を一緒にやる
オンコール対応のシャドウイング（実際の障害事例で慣れる）
実作業がイメージができる状態にして心理的負担を下げた
オンボーディング専用Slackチャンネルを作った
- ノイズが少ない＆質問しやすい
- メンター以外でもサポートしやすい
- 振り返りに使いやすい

入社後のフォローアップ、技術知識なら個人でもある程度は拾っていけますが、ドメイン知識（業務知識）や組織面の把握って確かに難しいですよね。OJTに近い形で依頼タスクや障害対応に触れられると早く身につけられそうです。

グループウォレットアプリ、6gramの運用をはじめてみた

speakerdeck.com

6gramは複数人で財布を共有できるウォレットアプリ、iOS版はもうすぐ
クレジットカード情報を取り扱うため「PCI DSS」の準拠が必要
アカウント要件がやや古かったり、セキュリティ要件が厳しかったり……
運用負荷を下げつつPCI DSSに準拠するために工夫してみた
- EC2を使わずFargateにする→サーバ内のアカウント管理が不要
- コンテナをreadonlyにする→改ざん検知の仕組みが不要
- データはDynamoDBに入れてKMSを使う→暗号化と運用をマネージドで完結
- バッチをCodeBuildで実行する→EC2を建てない、Lambdaでは時間が足りない
実際に↑の構成でPCI DSSに準拠することができた（審査が通った）
インシデント対応のシミュレーションを定期的に実施している
課題としては、可観測性が低くトレーシングやログがやや不十分
SREとしての専任はおらず、全員で開発・運用を行っている

決済というお固めの領域で、PCI DSSに準拠させながらいかに運用負荷を下げるか、というお話でした。難解な要件に対して次々と解決策を打ち出すテンポの良い発表で、「PCI DSSはパズルゲーム」という名言も登場。個人的には一番印象に残ったセッションでした。

急成長するPairsと共に変化・成長し続けてきたエウレカのSRE戦略

speakerdeck.com

サービスが急成長、累計会員数は1000万人を突破
特性上、DB ReadだけではなくWriteの負荷もかなり高い
DB設計の見直しとともに、アプリもフルスクラッチでGo言語にした
SREチーム立ち上げ時に、ミッションを明確に定めて行動指針とした
可用性99.95％を目指して、事業の機会損失を防ぐことが目標（の1つ）
アラートレベルを再設計、ユーザ影響度を基準にした
Fargateに移行してスケーラブルなシステムに
「SREは土木作業」ビジネスの土台を整えるのが大きな役割
振り返りにはKPTを採用
- Tryの中で最重要項目を1つ決めて、次のサイクルで確実に実施する

PairsのSREチーム、組織や運用方針よりの話が多めでした。SREは事業貢献の面での成果が見えづらい、というのはあるあるな気がしています。信頼性向上に限らず、価値提供のスピードアップを支援するなどのミッションを定めて合意しておくことは確かに重要かもと感じました。

SREがセキュアなWebシステムを構築、維持するためにやれることはなにか

speakerdeck.com

家族アルバムアプリ「みてね」、国内外から600万ユーザ以上が利用中
Kubernetes（EKS）への移行を実施中
SREとDevOpsの違い: class SRE implements DevOps
グローバルカンファレンスの「SRECon」が参考になる
脆弱性バジェット＝依存するソフトの脆弱性が問題になるまでの期間
レガシーバジェット＝OSやミドルウェアのサポート期限切れなど
よく整備されたロギングは脅威の検出と障害への備えになる
- ログ上に個人情報を書き出さない
- でもユーザIDはトレースできるようにしておきたい
- クラウドサービスのログ機能はなるべく有効化
有事の際の指揮系統・チェックリストなどを事前に定めておく
手間の掛かることは自動化する
脆弱性パッチは素早い適用が重要
コミュニケーションが重要
- 他チームとの間に壁を作らない、タスクを押し付け合わない
- ビジネスや事業の視点も持ってみる
- 新規開発時にヒアリングをしてみる（ミドルや設計の懸念点など）
依存しているソフトウェアやライブラリは定期的にアップデートする
ポストモーテムは積極的に作る、作成者を称賛する文化を作る、批判は絶対しない
AWSの責任共有モデルやWell-Architected Frameworkに目を通す
クラウド側のセキュリティサービスを活用する

SREが担当する領域の広さを再認識したセッションでした。なるべく設計段階からセキュリティを考慮し、問題が発見しやすい・対処しやすい・追いやすい環境を作ることが大事ですね。あとはクラウドの機能も揃ってきているので上手く活用しましょうと。

サイト信頼性エンジニアリングの原則

google.com

SREのモットー「Hope is not a strategy」
複雑性はコストである、一貫性を保っておくこと、例外はコスト高
プログラミング言語もなるべく統一できると望ましい
ステートフルな仕組みはなるべく減らす
モニタリングには大きく2種類の方法がある
- ホワイトボックス: 内部メトリクス
- ブラックボックス: 外形監視やSLAなど
アラートへの思いやりが大事
- 単なるメトリクス異常だけでSLOに響かない場合は通知しない
- 緊急度が低いものは通知せず、通常業務内で対応する
- オンコール対応が必要ないものはチケットで管理
メールは通知手段として適さない
- メーリス宛だと誰が主担当になるか分からない
- 同時に複数人動いたり、逆に誰も動かなかったりする
- メールを自発的に見ないと気づけない
モニタリングで信頼できる情報源を決めておく
- 複数のツールで似た値が取れる場合はどっちが正？
- 時計が1つなら時間を即答できるが、時計が2つあると判断に悩む
可用性が99.9％＝100％を達成できなかった、ではない
- 残りの0.1％を活用して改善やシステムのシンプル化に注力すること
- どちらかと言えば「0.1％までのダウンは許容できる」という考え方
デプロイ時にはロールバック手順も用意されていること
システムにも障害耐性をつける
- 再起動コマンドの実行前に設定ファイルが不正チェック
- 変更差分が明らかに多すぎる（20％以上等）なら一旦止める
障害対策テストは、可能なタイミングでいつでも実施しておく
ポストモーテムの運用
- 非難しない
- プロセスと技術に注目する
- 人間は修正できないので、仕組みや環境の方を修正する
- ダメな例: エンジニアが設定ファイルの変更を誤った
- 正しい例: 不正な設定ファイルが検証無しでデプロイされた
障害に早く気づくために監視頻度や監視対象を見直す
障害回復を早くするために、変更直前の設定を自動保存する仕組みなど
https://google.com/sre を読みましょう
SRE本は気になる部分だけでもいいから目を通した方がいい

エラーバジェットの考え方

可用性99.9％＝100％が達成できなかった、という意味ではない。残りの0.1％は改善や機能リリースなどに使える「予算」となり、0.1％のダウンタイムを活用して積極的な変更も可能となる。#srenext #srenextA
— yuu26/えむおん@SRE (@m_on_yu) January 25, 2020

SREの原則について、用語だけでなく具体例も交えて復習することができました。人はミスをする・システムは落ちる、といった前提を踏まえて仕組みを整えていくことが大事ですね。仕組みの作り込みはまさにソフトウェアエンジニアであって、インフラエンジニアとは別であることも実感。

SRE NEXT 2020 の感想

有料カンファレンスで人数上限もあったためか、混みすぎることもなくゆっくり過ごせました。休憩部屋・電源・Wi-Fiもしっかりと整えられており運営もスムーズで、ストレスなくセッションや交流に参加できたのも良かったです。

各社のSREチームが取り組んでいる工夫や、SREについての考え方も学び直すことができて非常に有意義なカンファレンスでした。 SRE本をベースとした発表が多かったため、書籍版を最近買ったSRE本をきちんと読んでみようと思います。

運営に携わった皆さん、発表された皆さん、会場でお話してくださった皆さん、ありがとうございました。

2019-12-22

LINE BotのUI機能まとめ（リッチメニュー・Flex Message・LIFFの活用方法）

この記事は、LINE Bot Advent Calendar 2019 の22日目です。
昨日は、@KMimさんの朝イチで知りたいことをLINEで教えてくれるプログラム(Python)でした。

LINE Botで使える3大UI機能「リッチメニュー」「Flex Message」「LIFF」の違いや、それぞれの機能がどんな場面で活用できそうかを解説します。

機能名	場所	使い方
リッチメニュー	トーク画面の下	ユーザ起点のアクションを受け取る
Flex Message	トーク画面	構造化されたデータを伝える
LIFF	内蔵ブラウザ	Webアプリを組み込める

リッチメニュー：ユーザ起点のアクションに

リッチメニューとは、LINEトーク画面の下にある画像メニューです。ユーザがアクションを起こすスタート地点に最適です。

クロネコヤマトのBotでは、再配達依頼・受取日時の変更・送り状発行などの呼び出し元に使われています。

最大で6つまでのアクションを埋め込めるため、主要な操作はリッチメニューに入れておくと便利です。

リッチメニューで出来ること

任意の画像をメニューとして表示する
タップされたらアクションを実行する
タップ時にテキストを投稿させる
タップ時にURLを内蔵ブラウザで開く
期間指定でメニュー内容を切り替える

メリット

サイズが大きいためユーザが気づきやすい
キャンペーン期間限定のお知らせ表示などが容易

デメリット

トーク画面内での占有率が高い

リッチメニューは、トーク画面を開いた際にデフォルト表示させることが可能です。ユーザに何らかの操作を促す場合は、デフォルト表示ONが良いかと思います。

Flex Message：Botからの情報提供に

Flex Messageとは、レイアウトの自由度が高いメッセージです。公式アカウントから届く見た目がきれいなメッセージは大体これです。

CSS Flexboxに近い仕組みで実装されており、コンテナの中に自由なレイアウトでコンテンツを入れ込むことができます。

LINE Developers より

ユーザに対して情報を提供する場合、テキスト単体ではなくFlex Messageを上手く活用することで可読性が向上します。

通常のテキスト	Flex Message

ユーザアクションをWebhookで受け取れる

Flex Messageにはボタンを埋め込むことができ、内蔵ブラウザでURLを開く・Webhook経由でサーバに文字列を送信するなどのアクションが登録可能です。

Webhookとしてリクエストを受け取れるため、サーバ側のイベント実装がシンプルになります。（テキスト対話で同じことを再現しようとすると、自然言語処理やバリデーションなど考慮する内容が多岐にわたり非常に面倒）

Flex Messageで出来ること

自由なレイアウトでメッセージを作成する
カルーセル形式で複数アイテムを表示する
メッセージ内に画像を埋め込む
アクションボタンを埋め込む

メリット

ユーザに読んでもらえる可能性が高い(?)
ユーザアクションをWebhookとして受け取れる

デメリット

レイアウトを組むための実装がやや面倒

汎用性が高い分、シンプルなメッセージでもやや面倒な実装が必要です。Flex Message Simulator や、LINE Messaging API SDK を上手く活用すると多少楽になります。

LIFF：LINEに組み込めるWebアプリ

LIFFとは、自作のWebアプリをLINEに組み込める機能です。外部にあるアプリケーションとLINE IDを連動させることもできます。

ユーザの同意があればWebアプリ側からLINEのユーザIDを取得できるため、自前の会員サービスと紐付けることで、個別のプッシュ通知や問い合わせ対応などが実現できます。

ヤマト運輸の例では、クロネコメンバーズとの連携時に出てくる画面がLIFFです。

クロネコ側はLIFF経由でこちらのLINE IDを把握できるため、LIFFブラウザ内でクロネコメンバーズにログインするだけで紐付けが完了します。

会員登録時の入力フォームとして使う

副業で携わった案件では会員登録フォームとしてLIFFを活用しました。既存のWebフレームワークが使えるため、Webアプリ側としてはフォームをただ1つ作っただけです。

テキストで「名前は？」「都道府県は？」「性別は？」と何往復するよりも早く、ドロップダウンや日付指定UIも使えて、送信前のバリデーションも載せられる便利さがあります。

LIFFで出来ること

任意のWebアプリを呼び出せる
ユーザの同意があればLINE IDを取得できる

メリット

Webの仕組みを使えるため実装の自由度が高い
自社のアカウントとユーザのLINEを紐付けできる
LINEの画面内で開くため離脱しづらい(?)

デメリット

Webサーバの外部公開が必要（コスト、セキュリティ、……）
LIFFを考慮した実装が必要
CookieやLocalStorageの利用は保証されない（現時点では動く）

LINE BotのUIまとめ

LINEには、構造化データを取り扱える仕組みが多数用意されています。

テキストでのやりとりを最小化し、リッチメニュー・FlexMessage・LIFFをなるべく活用しましょう。実装は面倒ですが、ユーザも開発者も幸せになれます。

機能名	場所	使い方
リッチメニュー	トーク画面の下	ユーザ起点のアクションを受け取る
Flex Message	トーク画面	構造化されたデータを伝える
LIFF	内蔵ブラウザ	Webアプリを組み込める

LINE Bot Advent Calendar 2019 22日目の記事でした。明日は、@masaki925さんが担当されます。

2019-05-19

Amazon Connect + AWS Lambda で、スプラトゥーン2のステージ情報を確認できる電話番号を作ってみた

Amazon Connect と AWS Lambda を使って、スプラトゥーン2のステージ情報が聞ける電話番号を作りました。100％お遊びネタです。

プッシュした番号に応じて、ナワバリバトル・ガチマッチ・リーグマッチの最新ステージ情報を返してくれます。試してみたい方は 050-3000-7540 からどうぞ。

Amazon Connect ＝ AWS の電話サービス

Amazon Connect とは、AWS が提供するコールセンター用のマネージドサービスです。電話番号の取得から Hello World の作成まで、5分ほどでサクッと作れてしまいます。

前回の記事で詳しく触れていますので、気になる方は合わせてご確認ください。

blog.yuu26.com

Amazon Connect と AWS Lambda を連動させる

Amazon Connect には、AWS Lambda との連携機能が用意されており、外部サービスと連動した電話サービスを実現できます。

今回は、自前の REST API でもある Spla2 API を使って、スプラトゥーン2のステージ情報を返すように実装しました。

問い合わせフローの完成図

完成した問い合わせフローは以下の通りです。使用したコンポーネントは5種類でした。

音声の設定
顧客の入力を保存する
AWS Lambda 関数を呼び出す
プロンプトの再生
切断／ハングアップ

Amazon Connect の問い合わせフロー

AWS Lambda のダミー準備

まずは固定の文言を返す簡単な Lambda を用意しておきます。

request モジュールを後ほど使うため、ローカルの作業場所で用意しましょう。

$ mkdir spla2-telephone
$ cd spla2-telephone
$ npm install request
$ vi index.js

index.js の中身は「現在のステージ情報は、ホゲです。」と返すだけの処理です。

用意したファイル一式を ZIP で固めて、Lambda にデプロイします。

$ zip -r ./lambda.zip index.js node_modules

Lambda のトリガーポリシーを設定する

今回の作業において一番分かりづらいのがココです。

Amazon Connect が AWS Lambda を呼べるように設定するのですが、Web コンソールが未対応のため CLI から設定する必要があります。詳しくは公式ドキュメントを参照。

aws lambda add-permission --function-name function:lambda-function-name --statement-id 1 \ 
     --principal connect.amazonaws.com --action lambda:InvokeFunction --source-account 999999999999 \ 
     --source-arn arn:aws:connect:ap-northeast-1:999999999999:instance/aaaaaaaa-bbbb-cccc-dddd-eeeeeeffffff

lambda-function-name : Lambda の関数名に置き換え
999999999999 : AWS アカウント番号に置き換え
aaaaaaaa-bbbb-cccc-dddd-eeeeeeffffff : Amazon Connect の ARN に置き換え

Amazon Connect の ARN は、管理コンソールからインスタンス名をクリックすると確認可能です。東京リージョン以外の場合は、リージョン名も書き換えてください。

Amazon Connect で入力値を受け取る

Lambda の準備ができたら次は Connect 側です。電話番号の取得や基本設定は前回記事で触れているため省略します。

Amazon Connect で入力値を受け取る

今回は、ユーザが欲しい情報を選択してもらうため、「顧客の入力を保存する」コンポーネントでプッシュボタンの番号入力を受け取ります。

Amazon Connect で入力番号を保存する

保存した番号を Lambda に渡して起動する

「AWS Lambda 関数を呼び出す」コンポーネントを使って、Lambda を起動できます。

起動する Lambda の ARN を入力し、引数として渡すパラメータも指定します。今回は「mode」というキーで、ユーザが電話入力した番号を渡すことにしました。

Amazon Connect から AWS Lambda を呼び出す

Lambda から返ってきた音声を読み上げる

Lambda から返ってきた結果を読み上げるため、「プロンプトの再生」コンポーネントを使います。

Lambda の実行結果は { "result": "結果のテキスト" } 形式で返すこととしたため、Amazon Connect 側では result を読み上げるように設定すれば OK です。

AWS Lambda の実行結果を読み上げる

テスト電話をかけてみる

フローの最後＆エラー発生時は「切断」するように設定し、問い合わせフローを電話番号に紐づけます。手順は前回記事を参照。

試しに電話をかけてみると、何番を押しても「ほげです」と返すようになりました。

スプラトゥーンのステージ情報を反映

あとは Lambda 側をせっせと実装するだけです。今回使用したのは、Splatoon2 のステージ情報を返す自作 API で、プッシュされた番号に応じて取得内容を切り替えています。

プッシュされた番号は event.Details.Parameters.mode で取得できます。末尾の「mode」は、Connect 側で設定したキー名です。

blog.yuu26.com

コールセンターの完成

AWS Lambda を保存すると即反映されます。選択した番号に応じて REST API を使い分け、最新の情報を読み上げてくれる電話番号が完成しました。

しばらくの間は 050-3000-7540 で公開しているので、試してみたい方はぜひ。番号非通知（184）で掛けてもちゃんと動きます。

Amazon Connect + AWS Lambda の連携まとめ

Amazon Connect から Lambda を呼び出せる
ユーザが電話入力した番号を Lambda に渡せる
Lambda が返したテキストを電話で読み上げできる
権限付与は CLI から設定する必要あり

今回は使いませんでしたが、Lambda の戻り値を見て Connect のフローを切り替えることも可能です。電話経由でサーバにコマンドを投げたり、色々な応用ができそうですね。

blog.yuu26.com

2019-05-19

Amazon Connect で、電話番号の新規取得から Hello World! までを5分で試す

Web AWS

Amazon Connect とは、AWS が提供するクラウド型のコールセンター機能です。

電話番号を新規取得して、事前登録したフローを自動音声で喋らせる、といった実装が簡単に実現できます。値段も安く、1番号×1日＝10円 ほどでお試しできます。

今回は「Hello World!　こんにちは、世界」と応答する電話番号を作ってみました。

Amazon Connect 初期設定

Amazon Connect コンソールから初期設定を行います。

コールセンター向けサービスのため、実際には複数人で利用するための ID 管理が必要です。今回はテストなので、一番簡単な「Amazon Connect 内にユーザーを保存」を選択。

Amazon Connect の初期設定（ユーザー情報の管理）

管理者情報を作成できますが、テスト用途では不要なのでスキップ。

Amazon Connect の初期設定（管理者情報の作成）

電話の用途を選択します。今回は受電（電話を受ける側）として使いたいので、着信のみにチェック。

Amazon Connect の初期設定（テレフォニーオプション）

コールセンター向けのため、通話記録を保存する機能も備えています。保存先の S3 バケットを変更可能です。

Amazon Connect の初期設定（データストレージ）

最後の画面、特に確認する内容もないのでそのまま「インスタンスの作成」をクリック。

Amazon Connect の初期設定（最終確認）

Amazon Connect で電話番号を取得

（良い意味で）AWS らしくないデザインのコンソールが出てきました。右上の言語を日本語に切り替えて「今すぐ始める」をクリック。

Amazon Connect のコンソール

電話番号の取得画面では、候補の中から希望する番号を選びます。（リロードで候補が変わる番号ガチャ）Toll Free はフリーダイヤルなので、値段お高め。

Amazon Connect の電話番号取得

今回はオペレーターによる通話を利用しないので、Skip for now を選択。これで一通りの設定は完了です。

Amazon Connect のエージェント設定

Amazon Connect で Hello World! のフローを作る

左メニューから「ルーティング→電話番号」を開くと、取得した番号を確認できます。サンプルフローが設定済みのため、電話をかけると英語の自動音声を聞くことができます。

Amazon Connect の電話番号一覧

電話フローを自分で変更するために、左メニューから「ルーティング→問い合わせフロー」を開き、「問い合わせフローの作成」をクリックするとエディタが開きます。

問い合わせフローの作成

左上に適当な名称「Hello World!」を入力し、設定カテゴリから「音声の設定」をフローに追加して繋げます。今回は「言語：日本語」「音声：Mizuki」を選択。

Amazon Connect の音声設定

続いて、操作カテゴリから「プロンプトの再生」を追加して接続。アイテムをダブルクリックすると、喋らせる内容をテキストで入力できます。

自動音声のテキスト設定

終わったら電話を切りましょう。終了／転送カテゴリから、「切断／ハングアップ」を選択して、フローの最後に繋げておきます。

問い合わせフローの切断処理

作成したフローを電話番号に反映する

右上のメニューから「保存して発行」を選択します。ただ保存しただけでは使えないので、発行を忘れないように注意が必要です。

Amazon Connect の問い合わせフロー保存

左メニューから「ルーティング→電話番号」を開き、先程取得した電話番号をクリック。問い合わせフローを、Hello World! に変更して保存します。

Amazon Connect の問い合わせフロー変更

反映までに1分ほど掛かる場合もありますが、実際に電話をかけてみると設定した音声が聞こえるはずです。

Amazon Connect の利用料金

AWS 公式サイトによると、東京リージョンでは以下の料金で利用できます。

種別	項目	料金
050電話	番号維持費	0.1ドル／1日
050電話	受信通話料	0.003ドル／1分
フリーダイヤル	番号維持費	0.48ドル／1日
フリーダイヤル	受信通話料	0.1482ドル／1分

050電話であれば、1ヶ月300円強＋通話料だけで利用できます。試した後は番号を削除すれば課金されないので、気軽に遊ぶことができますね。

AWS Lambda とも組み合わせ可能

Amazon Connect では、番号プッシュによるフローの振り分けや、Lambda と連携した返答にも対応しています。

Lambda なら何でもアリということで、スプラトゥーン2 のステージ情報を返す電話番号も作ってみました。

blog.yuu26.com

Amazon Connect のまとめ

AWS が提供するコールセンター向けサービス
複数人で1つの電話番号を利用して受電が可能
Web 上で設定したフローに基づいて、自動音声での対応が可能
フローの分岐や Lambda との連携も可能
値段もかなりお安い

Web 画面からポチポチ設定した内容が電話から聞こえてくるのは新鮮な経験でした。

2019-01-20

作業用 BGM に適した条件を考えてみた。個人的ベストは torne BGM

雑記

概要

作業時に BGM を流す方は多いと思います。

BGM の選択ひとつで作業効率が変わってくるため、作業 BGM に適した条件をまとめてみました。

歌詞が入っていない
テンポが早すぎない
思い入れが強すぎない
適度な長さがある

集中力を上げる作業用 BGM の条件

歌詞が入っていない

文章を打ったりコードを書いたり、頭を使う作業では歌詞が邪魔になりがちです。歌のない曲を選んだ方が集中できます。

逆に、部屋の掃除など体メインの作業であれば、歌詞付きでもOK。歌いながら楽しく作業を進められます。

テンポが早すぎない

テンポが早すぎると音楽にノッてしまって集中できない可能性があります。

かといって遅すぎると眠くなる可能性があるので、そこそこのテンポが望ましいです。

思い入れの強すぎない曲

個人的な思い入れのある曲や、ヘビロテしていた時期を思い出す曲など、思考が別のところに飛びやすい曲は避けましょう。

慣れるまで聞きまくれば何とかなりますが、それより別の曲を探したほうが早いです。

適度な長さがある

作業中に何度も BGM を操作するのは無駄でしかないので、最初からある程度の長さがあるものを選びましょう。

プレイリストを作ってループ再生にするだけでも OK です。

作業用 BGM を固定化するメリット

作業用 BGM が決まったら、一定期間使い続けて固定化するのもオススメです。固定化によって2つのメリットがありました。

BGM を選ぶ時間がゼロに

手を動かすときの BGM はこれ、と決めておけばすぐに作業を始められます。

BGM 探しに使っていた時間が浮くので有効活用しましょう。

作業モードのスイッチになる

いつもの BGM が流れると頭が作業モードに切り替わるようになりました。

習慣化テクニックとしても役立ちそうです。

作業用 BGM の選び方まとめ

思考の邪魔とならない BGM を選ぶ
放置しても流れ続けるようにする
固定化すると作業開始のトリガーになる

ぜひ自分に合った作業用 BGM を探してみてください。

2018-12-31

2018年の振り返りと2019年の目標について

雑記

気が向いたので2018年の振り返り。ついでに2019年の目標も。

2度目の転職をした

ご縁があり 5月から職場が変わりました。
自社サービスの Web 系企業で SRE として働いています。

最近は AWS・PHP・Node.js・Ansible・WordPress・社内 Bot 辺りが担当分野です。

チームや周りの技術レベルが高く、日々多くのことを学べています。新しいチャレンジが歓迎される環境 なのも嬉しいところ。

アプリのコードを書くことも増えて、単なるインフラエンジニアから少しステップアップできたかな、という感覚です。

人生初の手術を受けた

目の中にレンズを入れてサイボーグになりました。

最初はコンタクトレンズを検討していましたが、数十年先までの維持費と手間（時間）を考えた結果 ICL を受けてみることに。

20年間メガネ生活だったので裸眼はいまだに新鮮です。
視力が 2.0 まで向上したので文字通り見える世界が変わりました。

blog.yuu26.com

長期的な安全性などの不安がゼロとは言いませんが、リスクを取らずに新技術のリターンは得られない と考えているため、少なくとも現時点では大満足です。

（ただし手放しで人にオススメできるかと言われると時期尚早だと思います）

ブログが少しバズった

iPhone の機能を紹介した記事が少しバズりました。
多少狙って書いたものの、予想以上の反響で嬉しかったです。

blog.yuu26.com

ホッテントリに載ったり、テクノロジの TOP に載ったり、アクセス数が15倍になったり。はてブ500超えの自己記録を塗り替えるのは大変そうだ。

運動の習慣ができた

これは20代後半あるあるかもです。
運動不足を意識して、少しずつ 運動する習慣 をつけ始めました。

外を走ってみたりジムに行ってみたり。
最近は頻度が下がりつつあるので、来年は定着させることが目標です。

運動について調べたところから派生し、健康や食事面も気にするようになりました。

副業を始めた

本業と同じ分野の副業 を始めました。
サーバ関連の作業や小規模開発の案件を中心に受けています。

本業から少し外れた知識を要することも多く、「副収入」というよりも「技術の幅を広げる」という意味で楽しくやれています。

本を読む時間が増えた

久しぶりに本を読むようになりました。Kindle と図書館の組み合わせ。

気になる技術の本・雑誌・ビジネス本・小説などジャンルはごちゃ混ぜですが、月に数冊も読んだのは中学校以来で 知る楽しさ を思い出してきました。

語彙力の向上も目指しつつ今後も継続しようと思います。

文字を書く量が増えた

表立って公開はしていませんが、ほぼ毎日どこかで文章を書いています。

このブログ以外にも、会社のブログ・技術系のネタ・趣味の分野・勉強中の分野……、諸々を合わせると300記事ほどです。

書くことで頭の中を整理できたり、確度を高めるために調べなおしたり、新しい知識を身に着けたり、小さいけど広告収入が入ってきたり、数多くのメリットがありました。

時間の使い方を改善した

運動・副業・読書・文字書きなどの取り組みが増えた分、かなり意識して1日の時間配分を変えました。

やるときはやる、遊ぶときは遊ぶ のメリハリが大事ですね。

会社や家を問わず「やることリストを作って消化する」リズムができたので、ゴロゴロするだけの無駄な時間は大幅に減りました。

ただしまだバランスが崩れることも多く、生活リズムの安定化が来年の課題です。

来年の目標

コードのコミット量を昨年より増やす
Web サービスを複数リリースする
運動習慣を定着させる
情報発信の質と量を増やす
副業収入を増加させる
自分の売り出し方を考える
生活リズム（就寝時刻）を整える

表に出せる情報だけだとふわっとしますね。
手元ではもう少し具体的な振り返りと目標を書いていたりします。

自分の売り方については、セルフブランディングのお手本のような人が身近にいるので新しいチャレンジが増えそうな予感です。

目標を達成するために

自分の行動のみで達成できる目標設定を心がけています。
他者に依存したり、環境に左右される内容・数値はなるべく避けています。

（例）サイトで言えば PV 数 ではなく 更新頻度 を目標値にする、など

また、1年単位の目標だけだと「夢見がちな内容」になったり「行動を先送りしがち」なことが、経験から分かってきました。

そのため、実際は月単位で「今月やること」を決めなおしていたりします。この取り組みは上手く機能したので来年も継続予定。

まとめ

2018年は、周りの環境も自分自身も大きく変わった（変えられた）1年でした。

何やらエモい内容になりましたが、2019年もよろしくお願いします。

2018-11-28

JR駅の作業スペースステーションワーク（ステーションブース）が快適だった

スポット紹介

JR の駅構内で使える作業スペース「ステーションワーク」を試してきました。

https://www.stationwork.jp/www.stationwork.jp

電話ボックス型で机と椅子があり、思いのほか快適に過ごすことができたため紹介します。現在は実証実験中のため無料で使えます。

ステーションワークの第1弾「ステーションブース」

JR 東日本が始めたシェアオフィス事業で、「ステーションワーク」という名称です。第1弾は都内3駅で実施され、現在は第2弾として立川駅で運用中です。

~~期間： 2018/11/28 ～ 2019/02/20~~
~~場所：東京駅・新宿駅・品川駅~~
期間： 2019/05/10 ～
時間： 09:00 ～ 21:00
場所：立川駅
台数：駅ごとに4台ずつ
対象：個人および法人
料金：無料
予約： 15分 or 30分枠
制限： 1人あたり1日30分まで

個室型の ステーションブース 以外にも、コワーキング型の ステーションデスク や、会議室型の ステーションオフィス が登場予定です。

ただし、個人会員で使えるのは ステーションブースのみ となります。

スペース内の設備

見た目はただの電話ボックスですが、中の設備は意外と充実していました。

デスク＆イス
足元の暖房
24インチモニタ
スピーカー
Web カメラ（USB-A 接続）
電源コンセント1つ
充電用 USB ポート
Wi-Fi
傘立て
非常ボタン

広さは大人が一人ゆったりと座れるくらいで、座り心地は電車のシートに近いです。
30分程度なら快適に過ごせると思います。食事は NG、飲み物だけ OK でした。

モニタの接続端子は HDMI のみで、VGA や USB-TypeC などは接続できません。

天井には照明・換気扇・スピーカーがあり、入室時と退室時刻の5分前に音声アナウンスが流れてきます。（初日で不調なのか、退室アナウンスは鳴りませんでしたが……）

ブース内の Wi-Fi が速い

ブース内で使える無料 Wi-Fi が速くて快適でした。

802.11ac で提供されており、上り・下りともに 100Mbps 以上は出ています。NTTcom 系の回線でした。

通勤ラッシュの駅構内でも快適

今回は、朝9時の品川駅で試してみました。
朝の品川をご存知の方は想像がつくと思いますが、ブースの外は人だらけです。

大混雑の駅内でデスクに PC を広げて過ごす という新鮮な感覚を味わえました。
設置されて日が浅いこともあってか、出入りの際もかなり目立ちます。

しかし外からは見えない作りになっており、遮音性も高いため作業には集中できました。ブースは狭いものの、余計な誘惑が視界に入らない点はメリットかも知れません。

想定される活用方法

パッと浮かぶところでは、次のような活用方法がありそうです。

急な作業が必要になったとき
騒がしい駅から電話を掛けたいとき
仮眠を取りたいとき
待ち合わせまで時間が余ったとき
運転見合わせで足止めを食らったとき

駅で足止めとなったときは、早いもの勝ちですぐに埋まりそうな予感がします。

車でもない限りは、なかなか出先でパーソナルスペースを確保できないため、様々な活用方法がありそうですね。

「ステーションブース」利用の流れ

操作はすべて Web 画面上で完結します。
https://www.stationwork.jp/

Web サイトで会員登録
場所と時間を指定して予約
予約時刻になったらブースへ
ブースの QR コードを読み取り
利用開始

ブラウザ上でカメラを起動して QR コードを読むという処理に驚きました。最近の Web アプリはすごい。

ちなみに、予約のない空き時間であれば QR の読み取りだけですぐに使えます。

JR 東日本「ステーションワーク」のまとめ

駅構内に設けられたコワーキングスペース
第1弾は、公衆電話に近いブース型
電源、Wi-Fi、外部モニタ、空調を完備
30分以内のちょっとした作業には最適
~~場所は、東京・新宿・品川の改札内~~
~~2019年2月までは無料で利用可能~~
2019年5月からは立川駅で実証実験中（無料）

運用開始時の価格が気になるところですが、設置場所が増えてくると便利に使えそうです。

実証実験中の駅が近い方は、ぜひ一度試してみると良いと思います。

SECCON 2018 Online CTF Writeup - QRChecker

CTF

概要

SECCON 2018 Online CTF の Writeup 2問目です。
QR コードチェッカーのコードを読み解き、画像を作り出す問題です。

開催時間中には解けませんでしたが、記録として残します。

QRChecker

問題は以下のサイトで公開されています。
http://qrchecker.pwn.seccon.jp/

まずは公開されている Python のソースコードを確認。
HTML 出力部分は無視して、QR コードの処理周りを抜粋しました。

codes = set()
sizes = [500, 250, 100, 50]

data = form["uploadFile"].file.read(1024 * 256)
image= Image.open(io.BytesIO(data))

for sz in sizes:
    image = image.resize((sz, sz))
    result= zbarlight.scan_codes('qrcode', image)
    if result == None:
        break
    if 1 < len(result):
        break
    codes.add(result[0])

for c in sorted(list(codes)):
    print(c.decode())

if 1 < len(codes):
    print("SECCON{" + open("flag").read().rstrip() + "}")

フラグの出力処理を確認

たどり着きたいのはこの部分のコードです。

if 1 < len(codes):
    print("SECCON{" + open("flag").read().rstrip() + "}")

codes には QR コードの読み取り結果を格納しているため、どうにかして2件以上の QR コードを認識させる必要があります。

1回で1つの QR コードしか認識しない

QR コードの読み取り部分を見てみます。
result に2件以上の結果が格納されると、break で処理が終わってしまいます。

for (略):
    result= zbarlight.scan_codes('qrcode', image)
    if result == None:
        break
    if 1 < len(result):
        break
    codes.add(result[0])

アップロードできる画像は1つだけですが、2つ以上の QR が認識されるとアウトです。
でも、フラグを得るためには2つ以上の QR を認識させたいのです。

リサイズ処理で QR コードを変化させる

ここで、QR 判定の直前に行われているリサイズ処理に注目します。

500x500, 250x250, 100x100, 50x50 の4サイズが定義されており、リサイズ後に QR コードの読み取りを行うところがポイントです。

codes = set()
sizes = [500, 250, 100, 50]

for sz in sizes:
    image = image.resize((sz, sz))
    result= zbarlight.scan_codes('qrcode', image)
    if result == None:
        break
    if 1 < len(result):
        break
    codes.add(result[0])

for c in sorted(list(codes)):
    print(c.decode())

例えば、500x500 と 100x100 で読み取り結果の変わる QR コードが用意できれば、最終的に2件の QR を codes に格納できるはずです。

2種類の QR コードを用意して入れ子に

QR コードの誤り訂正を逆手に取れば何とかなりそうです。
a と b の文字を入れた QR コードを用意。QR のススメなどで生成できます。

f:id:yuu2634:20181028164619p:plain 　 f:id:yuu2634:20181028164704p:plain

b の画像を大きめに拡大して、その中に a の QR コードを埋めたのがこちら。
この QR コードでは、内側の a が認識されます。

f:id:yuu2634:20181028170831p:plain:w320

同じ画像を 100x100 にリサイズすると、
内側が潰れて読めなくなるため、今度は外側の b が認識されます。

f:id:yuu2634:20181028170837p:plain

フラグ獲得

SECCON の回答サーバに画像をアップロードするとフラグが出力されました。

f:id:yuu2634:20181028170856p:plain

SECCON{50d7bc7542b5837a7c5b94cf2446b848}

ThinkCentre M75q-1 Tinyの概要

購入した背景

PCに求める要件

ThinkCentre M75q-1 Tiny が良さそう

今後拡張できる余地がある

安く買う方法

自宅でセットアップ

M75q-1 Tiny を開けてみる

ThinkCentre M75q-1 Tinyのまとめ

参加したセッション

40000コンテナを動かすSREチームに至るまでの道

パフォーマンスを最大化するためのSREのオンボーディング事例

グループウォレットアプリ、6gramの運用をはじめてみた

急成長するPairsと共に変化・成長し続けてきたエウレカのSRE戦略

SREがセキュアなWebシステムを構築、維持するためにやれることはなにか

サイト信頼性エンジニアリングの原則

SRE NEXT 2020 の感想

リッチメニュー：ユーザ起点のアクションに

リッチメニューで出来ること

メリット

デメリット

Flex Message：Botからの情報提供に

ユーザアクションをWebhookで受け取れる

Flex Messageで出来ること

メリット

デメリット

LIFF：LINEに組み込めるWebアプリ

会員登録時の入力フォームとして使う

LIFFで出来ること

メリット

デメリット

LINE BotのUIまとめ

Amazon Connect ＝ AWS の電話サービス

Amazon Connect と AWS Lambda を連動させる

問い合わせフローの完成図

AWS Lambda のダミー準備

Lambda のトリガーポリシーを設定する

Amazon Connect で入力値を受け取る

保存した番号を Lambda に渡して起動する

Lambda から返ってきた音声を読み上げる

テスト電話をかけてみる

スプラトゥーンのステージ情報を反映

コールセンターの完成

Amazon Connect + AWS Lambda の連携まとめ

Amazon Connect 初期設定

Amazon Connect で電話番号を取得

Amazon Connect で Hello World! のフローを作る

作成したフローを電話番号に反映する

Amazon Connect の利用料金

AWS Lambda とも組み合わせ可能

Amazon Connect のまとめ

概要

集中力を上げる作業用 BGM の条件

歌詞が入っていない

テンポが早すぎない

思い入れの強すぎない曲

適度な長さがある

作業用 BGM を固定化するメリット

BGM を選ぶ時間がゼロに

作業モードのスイッチになる

おすすめ作業用 BGM

torne のホーム画面 BGM

（良い意味での）副作用

おまけ

ゲーム音楽

音楽配信サービスのプレイリスト

Youtube やニコニコで探す

作業用 BGM の選び方まとめ

2度目の転職をした

人生初の手術を受けた

ブログが少しバズった

運動の習慣ができた

副業を始めた

本を読む時間が増えた

文字を書く量が増えた

時間の使い方を改善した

来年の目標

目標を達成するために

まとめ

ステーションワークの第1弾「ステーションブース」