Yamaha RTX 810 で Azure の VNet ゲートウェイと BGP 接続する

ExpressRoute はなかなか触れるものでは無いので、仮想ネットワーク ゲートウェイ で BGP を試してみました。
対向のデバイスは RTX810 です。

IPSec に関して、以前はルートベース(IKEv2)のコンフィグが公開されていませんでしたが、今は対応しているコンフィグが公開されているので基本コピペで行けます。
BGP の設定に関しては、neighbor の ignore-capability=on さえ忘れなければうまくつながる(はず)です。

Azure の設定

Azure の設定としては、次のリソースの設定をする必要があります。

後で変更できなくて一番時間がかかるのは 仮想ネットワーク ゲートウェイ なので SKU の選択だけは慎重にする必要があります。

仮想ネットワーク ゲートウェイ

仮想ネットワークゲートウェイ(以下VNetGW)は、BGP が利用できる SKU が決まっており、VpnGw1/VpnGw2/VpnGw3 を選択する必要があります。
VNetGW は特に作成に20~30分かかるので SKU 選択は注意しましょう。

f:id:mitsuki0820:20181029103409p:plain

最初の作成画面で BGP の ASN の設定とかもできますが、後で変更できます。
ちなみに BGP の設定は構成の画面から設定できます。この設定は、あとでルーターに設定するときに使います。
この ASN は、Azure 側のルーターの ASN です。
f:id:mitsuki0820:20181029103731p:plain

ローカル ネットワーク ゲートウェイ

Azure から見たローカルの設定です。こちらも構成から設定します。

  • IP アドレス : ルーターのグローバル IP アドレスです。
  • アドレス : ルーター配下のローカルのネットワークですが、BGP の場合は、ピアとなるルーターの IP アドレスのみでいいので、/32で指定できます。
  • BGP 設定の構成 : こちらはローカル側の ASN/ピアの設定です。

f:id:mitsuki0820:20181029104227p:plain

接続

ローカルとの接続設定です。ここで設定するのは IPSec のための 共有キー と BGP の有効化の設定です。
特に共有キーは間違えないようにしましょう。BGP は有効にするだけです。が、これまでの設定ができていないとエラーが出ます。
f:id:mitsuki0820:20181029104819p:plain

とりあえず BGP と接続するだけなら Azure の設定はこれくらいで複雑な設定はありません。

このあたりのドキュメントが参考になります。
Azure VPN Gateways: Resource Manager: PowerShell で BGP を構成する | Microsoft Docs

ルーター

ルーター側の設定としては、まずは IPSec で接続して、そのあとに BGP でピアを張る形になります。

IPSec の設定

基本↓の設定でそのまま行けます。VPN よく張ってる人なら悩むことはないと思います。
Microsoft AzureとVPN(IPsec IKEv2)接続するルーターの設定 : コマンド設定

ここでは ipsec sa policy 1 1 esp aes256-cbc sha256-hmac anti-replay-check=off とかのゲートウェイ IDをそのままコピペしないように(1であればもちろん問題ないですが)しましょう。
(恥ずかしながら私はこんなところではまってました。。)

BGP の設定

BGP に関しても基本こちらのドキュメントの設定で行けます。
BGP-4 設定ガイド

が、1点、ignore-capability=on という設定を入れてあげる必要があります。ここに一番はまりました。。
BGP のプロトコルとして、使用できる機能(capability)という概念があるのですが、そのネゴシエーションで一致しなかった場合でも接続してしまうかどうか(無視するかどうか)を設定するオプションです。
色々調べていた時に、↓のJANOG の資料を何となく眺めていてもしやと思い、これを on にすると無事接続できました。

https://www.attn.jp/maz/p/t/pdf/janog41-bgp-tutorial.pdf

ちなみに、こんなエラーが出てきます。

2018/10/29 12:35:25: [BGP] Neighbor 172.21.1.254 (External AS 65001) Event [Start]  State [Idle] -> [Active]
2018/10/29 12:35:25: [BGP] Neighbor 172.21.1.254 (External AS 65001) Event [RecvOpen]  State [OpenSent] -> [Idle] 
↑------------------------------------------------- ここ ------------------------------------------------- ↑
2018/10/29 12:35:25: [BGP] SEND 192.168.1.1 -> 172.21.1.254 type 3 (Notification) length 21
2018/10/29 12:35:25: [BGP] RECV 172.21.1.254 -> 192.168.1.1 type 1 (Open) length 63
2018/10/29 12:35:25: [BGP] SEND 192.168.1.1 -> 172.21.1.254 type 1 (Open) length 29
2018/10/29 12:35:25: [BGP] Neighbor 172.21.1.254 (External AS 65001) Event [Open]  State [Connect] -> [OpenSent]
2018/10/29 12:35:25: [BGP] Neighbor 172.21.1.254 (External AS 65001) Event [ConnectRetry]  State [Active] -> [Connect]

BGP の遷移として、OpenSent -> OpenConfirm となるべきところが、Idle に戻ってしまっています。
これが延々繰り返されます。

ちなみに最終的な設定です。

bgp use on
bgp autonomous-system 65050
# ロギングの設定。設定中は必須。
bgp log neighbor packet
# 東日本(bgptest-gw) へのピア
bgp neighbor 1 65001 172.21.1.254 hold-time=30 gateway=tunnel5 local-address=192.168.1.1 ignore-capability=on
# 西日本(bgptest-gw-west) へのピア
bgp neighbor 2 65002 10.10.1.254 hold-time=30 gateway=tunnel1 local-address=192.168.1.1 ignore-capability=on
bgp router id 192.168.1.1
# ローカルのルートをアドバタイズする設定
bgp import filter 1 include 192.168.0.0/16
# 全てのルートをアドバタイズする設定
bgp import filter 100 include 0.0.0.0/0
# 静的経路のうち、192.168.0.0/16(filter 1で定義) のルートを ASN:65001 にアドバタイズ
bgp import 65001 static filter 1
# BGP の経路のすべて(filter 100)のルートを ASN:65001 にアドバタイズ
bgp import 65001 bgp 65002 filter 100
# 静的経路のうち、192.168.0.0/16(filter 1で定義) のルートを ASN:65002 にアドバタイズ
bgp import 65002 static filter 1
# BGP の経路のすべて(filter 100)のルートを ASN:65002 にアドバタイズ
bgp import 65002 bgp 65001 filter 100

最後に、 bgp configure refresh を忘れずに。

やってみた構成

せっかく時間をかけて GW を作ってみたのでいろいろ検証してみました。
構成を以下の様にしてみました。

  • RTX からそれぞれ IPSec で接続
  • 東日本と西日本に GW を作成
  • 東日本、西日本にそれぞれ複数の仮想ネットワークを接続し、VNet ピアリングで接続
  • RTX の ASN は 65050、東日本は 65001、西日本は 65002
  • 東日本のルートを西日本へ、西日本のルートを東日本にアドバタイズ
  • ホールドタイムを 30 に(特に意味はなく本当に変わるのかの確認)

f:id:mitsuki0820:20181031201416p:plain

RTX の状態

それぞれの AS からルートが流れていることが確認できます。

(抜粋)
RTX810# show ip route
Destination         Gateway          Interface       Kind  Additional Info.
default             -                    PP[01]    static  filter:20,21,22,40,41
default             -                    PP[01]    static  filter:9,12
default             -                    PP[01]    static  filter:11
10.2.1.0/24         -                 TUNNEL[3]    static
10.10.0.0/16        -                 TUNNEL[1]       BGP  path=65002
10.10.1.254/32      -                 TUNNEL[1]    static
10.12.0.0/16        -                 TUNNEL[1]       BGP  path=65002
172.21.0.0/16       -                 TUNNEL[5]       BGP  path=65001
172.21.1.254/32     -                 TUNNEL[5]    static
172.24.0.0/24       -                 TUNNEL[5]       BGP  path=65001
172.24.1.0/24       -                 TUNNEL[5]       BGP  path=65001
172.24.2.0/24       -                 TUNNEL[5]       BGP  path=65001
192.168.1.0/24      192.168.1.1           VLAN1  implicit
192.168.1.1/32      -                 TUNNEL[5]       BGP  path=65001
192.168.2.0/24      192.168.2.2           VLAN2  implicit
192.168.10.0/24     -                 TUNNEL[2]    static

東日本から受け取ったルート、アドバタイズしたルートが確認できます。

RTX810# show status bgp neighbor 172.21.1.254 received-routes
Total routes: 5
*: valid route
  Network            Next Hop        Metric LocPrf Path
* 172.21.0.0/16      0.0.0.0                       65001 IGP
* 172.24.0.0/24      0.0.0.0                       65001 IGP
* 172.24.1.0/24      0.0.0.0                       65001 IGP
* 192.168.1.1/32     0.0.0.0                       65001 IGP
* 172.24.2.0/24      0.0.0.0                       65001 IGP

RTX810# show status bgp neighbor 172.21.1.254 advertised-routes
Total routes: 4
*: valid route
  Network            Next Hop        Metric LocPrf Path
* 192.168.1.0/24     192.168.1.1                   65050 IGP
* 192.168.2.0/24     192.168.1.1                   65050 IGP
* 10.10.0.0/16       192.168.1.1                   65050 65002 IGP
* 10.12.0.0/16       192.168.1.1                   65050 65002 IGP

西日本から受け取ったルート、アドバタイズしたルートが確認できます。

RTX810# show status bgp neighbor 10.10.1.254 received-routes
Total routes: 3
*: valid route
  Network            Next Hop        Metric LocPrf Path
* 10.10.0.0/16       0.0.0.0                       65002 IGP
* 10.12.0.0/16       0.0.0.0                       65002 IGP
  192.168.1.1/32     0.0.0.0                       65002 IGP

RTX810# show status bgp neighbor 10.10.1.254 advertised-routes
Total routes: 7
*: valid route
  Network            Next Hop        Metric LocPrf Path
* 172.21.0.0/16      192.168.1.1                   65050 65001 IGP
* 172.24.0.0/24      192.168.1.1                   65050 65001 IGP
* 172.24.1.0/24      192.168.1.1                   65050 65001 IGP
* 172.24.2.0/24      192.168.1.1                   65050 65001 IGP
* 192.168.1.0/24     192.168.1.1                   65050 IGP
* 192.168.1.1/32     192.168.1.1                   65050 65001 IGP
* 192.168.2.0/24     192.168.1.1                   65050 IGP

あとはキープアライブ、ホールドタイムがちゃんと変わっているか見てみました。
RTX の場合、キープアライブは、ホールドタイムの 1/3 なので今回は10秒です。
IPSec を切断してみたところ、Update も大体30秒後くらいに出て、ルーティングテーブルから消えていました。

2018/10/31 21:36:18: [BGP] RECV 10.10.1.254 -> 192.168.1.1 type 4 (KeepAlive) length 19
2018/10/31 21:36:12: [BGP] SEND 192.168.1.1 -> 172.21.1.254 type 4 (KeepAlive) length 19
2018/10/31 21:36:10: [BGP] SEND 192.168.1.1 -> 10.10.1.254 type 4 (KeepAlive) length 19
2018/10/31 21:36:09: [BGP] RECV 172.21.1.254 -> 192.168.1.1 type 4 (KeepAlive) length 19
2018/10/31 21:36:08: [BGP] RECV 10.10.1.254 -> 192.168.1.1 type 4 (KeepAlive) length 19
2018/10/31 21:36:02: [BGP] SEND 192.168.1.1 -> 172.21.1.254 type 4 (KeepAlive) length 19
2018/10/31 21:36:01: [BGP] RECV 172.21.1.254 -> 192.168.1.1 type 4 (KeepAlive) length 19
Azure の状態

Azure の PowerShell で見てみます。

まずは GW の状態。

> Get-AzureRmVirtualNetworkGatewayBGPPeerStatus -VirtualNetworkGatewayName bgptest-gw -ResourceGroupName bgptest

LocalAddress Neighbor    Asn   State     ConnectedDuration RoutesReceived MessagesSent MessagesReceived
------------ --------    ---   -----     ----------------- -------------- ------------ ----------------
172.21.1.254 192.168.1.1 65050 Connected 00:45:11.8993646  4              816          800

> Get-AzureRmVirtualNetworkGatewayBGPPeerStatus -VirtualNetworkGatewayName bgptest-gw-west -ResourceGroupName bgptest

LocalAddress Neighbor    Asn   State     ConnectedDuration RoutesReceived MessagesSent MessagesReceived
------------ --------    ---   -----     ----------------- -------------- ------------ ----------------
10.10.1.254  192.168.1.1 65050 Connected 00:45:39.2323757  6              401          380


東日本の GW からアドバタイズしたルート、RTXから受け取ったルート

> $VgwName = 'bgptest-gw'
> Get-AzureRmVirtualNetworkGatewayAdvertisedRoute -VirtualNetworkGatewayName $VgwName -ResourceGroupName $RGName -Peer 192.168.1.1

LocalAddress Network        NextHop      SourcePeer Origin AsPath Weight
------------ -------        -------      ---------- ------ ------ ------
172.21.1.254 172.21.0.0/16  172.21.1.254            Igp    65001  0
172.21.1.254 172.24.0.0/24  172.21.1.254            Igp    65001  0
172.21.1.254 172.24.1.0/24  172.21.1.254            Igp    65001  0
172.21.1.254 192.168.1.1/32 172.21.1.254            Igp    65001  0
172.21.1.254 172.24.2.0/24  172.21.1.254            Igp    65001  0

>  Get-AzureRmVirtualNetworkGatewayLearnedRoute  -VirtualNetworkGatewayName $VgwName -ResourceGroupName $RGName 

LocalAddress Network        NextHop     SourcePeer   Origin  AsPath      Weight
------------ -------        -------     ----------   ------  ------      ------
172.21.1.254 172.21.0.0/16              172.21.1.254 Network             32768
172.21.1.254 172.24.0.0/24              172.21.1.254 Network             32768
172.21.1.254 172.24.1.0/24              172.21.1.254 Network             32768
172.21.1.254 192.168.1.1/32             172.21.1.254 Network             32768
172.21.1.254 192.168.1.0/24 192.168.1.1 192.168.1.1  EBgp    65050       32768
172.21.1.254 192.168.2.0/24 192.168.1.1 192.168.1.1  EBgp    65050       32768
172.21.1.254 172.24.2.0/24              172.21.1.254 Network             32768
172.21.1.254 10.12.0.0/16   192.168.1.1 192.168.1.1  EBgp    65050-65002 32768
172.21.1.254 10.10.0.0/16   192.168.1.1 192.168.1.1  EBgp    65050-65002 32768

西日本の GW からアドバタイズしたルート、RTXから受け取ったルート

> $VgwName = 'bgptest-gw-west'
> Get-AzureRmVirtualNetworkGatewayAdvertisedRoute -VirtualNetworkGatewayName $VgwName -ResourceGroupName $RGName -Peer 192.168.1.1

LocalAddress Network        NextHop     SourcePeer Origin AsPath Weight
------------ -------        -------     ---------- ------ ------ ------
10.10.1.254  10.10.0.0/16   10.10.1.254            Igp    65002  0
10.10.1.254  10.12.0.0/16   10.10.1.254            Igp    65002  0
10.10.1.254  192.168.1.1/32 10.10.1.254            Igp    65002  0

>  Get-AzureRmVirtualNetworkGatewayLearnedRoute  -VirtualNetworkGatewayName $VgwName -ResourceGroupName $RGName

LocalAddress Network        NextHop     SourcePeer  Origin  AsPath      Weight
------------ -------        -------     ----------  ------  ------      ------
10.10.1.254  10.10.0.0/16               10.10.1.254 Network             32768
10.10.1.254  10.12.0.0/16               10.10.1.254 Network             32768
10.10.1.254  192.168.1.1/32             10.10.1.254 Network             32768
10.10.1.254  192.168.1.0/24 192.168.1.1 192.168.1.1 EBgp    65050       32768
10.10.1.254  192.168.2.0/24 192.168.1.1 192.168.1.1 EBgp    65050       32768
10.10.1.254  172.24.2.0/24  192.168.1.1 192.168.1.1 EBgp    65050-65001 32768
10.10.1.254  172.24.1.0/24  192.168.1.1 192.168.1.1 EBgp    65050-65001 32768
10.10.1.254  172.24.0.0/24  192.168.1.1 192.168.1.1 EBgp    65050-65001 32768
10.10.1.254  172.21.0.0/16  192.168.1.1 192.168.1.1 EBgp    65050-65001 32768
Azure の仮想マシンから確認

JPEAST-Stagin の仮想マシン
JPEAST-Staging に VM を立ててみて、有効なルートから見てみました。
f:id:mitsuki0820:20181031210305p:plain
ちゃんと RTX からアドバタイズされているものが登録されています。

また、JPWEST-Production に traceroute してみたところ、RTX を経由してたどり着きました。

[tsunomur@vm2 ~]$ traceroute 10.12.0.4
traceroute to 10.12.0.4 (10.12.0.4), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  10.572 ms  11.485 ms  12.123 ms
 2  10.12.0.4 (10.12.0.4)  28.158 ms  28.156 ms  28.145 ms
他やってみたこと
  • JPEAST-Staging - bgptest-vnet 間のピアリング削除した状態 : JPEAST-Stagin -> bgptest-vnet の通信はできない。当然 RTX への通信もできない。
  • [ゲートウェイ転送を許可する]、[リモートゲートウェイを使用する]オプションを無効 : JPEAST-Stagin -> bgptest-vnet の通信はできない。

また、JPEAST-Common の VM から、JPWEST-Production への VM は、グローバル VNet ピアリングが優先されるため、RTX を通ることはありません。

まとめ

BGP の機能としてはもっとありますが、ちょっと触ってみるくらいであればそんなに難しくはないなと思いました。
ただNW機器は、ベンダーやファームウェアのバージョンの違いで相性みたいなものがあるので検証は必須だなというのを身をもって思い知らされました。。
さらに大きな規模な環境・複雑な構成で運用するとなった場合、日々の監視やHWのメンテ、HW故障時(もしくは Azure 障害時)の対応とか考えるとちゃんと運用できる体制を整えておかないといけないですね。

builderscon tokyo 2018 に参加した

ブログを書くまでがbuildersconということでちょっと遅くなったけど書く。

登壇

Azure ネタで登壇しようと思ったのでスピーカーで応募したら、なんと採択いただいた。何だかんだ、YAPC時代から含めると3回くらい登壇させていただいている。

今回は AWS 一辺倒の中 Azure でしかもエンタープライズネタということで、たぶん来ていただける人も少ないだろうなぁと思っていたら、予想通り満員御礼のセッションもある中10名くらいだったorz
※土曜日朝の10時から、しかもkazuhoさんの大人気のセッションの裏という枠もなかなか酷だなとは思っていたけどこれはいいわけです。。

内容としては、普段の業務から感じているエンタープライズへのクラウド導入特有の課題や解決策を話した。参加いただいた方からのご質問や反応から、今回話した内容はやはりエンタープライズ系のあるあるっぽい。
コンテナ利用を考えられている参加者の方もいらっしゃった。

また今度も何かのネタで応募したいと思うけど、タイトルやセッション内容の紹介文、スライドのつくりを改善していこうと思った。

前夜祭

電子名札を筆頭に IoT ネタ多めだった。闇を聞いていると前職での組み込み開発の時を思い出してそういうのあるよなぁみたいなところがあった。Akerun の事例なんかは IoT のデバイス側だけでなくて、いくらでもあるコントロールする側のデバイスのことも考慮しないといけないのでかなり手間かかりそう。

自分も何年か前に買ったラズパイ思い出して、改めてちゃんと触ってみたいなと思った。

1日目

オープニング

動画がすごい手が込んでて面白かった。今年向けに作ってあったけど来年はまた別のものになるんだろうか。。編集で何とかなるのかな。

産業でガチ利用されるRaspberry Piの話

前夜祭の Akerun の方のお話し。ラズパイって実はいろんなところで使われてて教育向けのおもちゃとか、日曜プログラマの領域だけではないっぽい。
生産も安定していて、品質も高い、その上安い、ということでこういうデバイスの中ではトップクラスに扱いやすいイメージを受けた。普段 OS 周りやクラウド、アプリケーションのレイヤにいると生産性とか品質の高さって全く意識しないので新しい発見だった。

パスワードレスなユーザー認証時代を迎えるためにサービス開発者がしなければならないこと

AuthN とかのはなし。認証系のデモは全く刺さらない、というぼやきは全くその通りだと思った。。
自分もOpenID Connectと Azure AD を組み合わせたアプリケーション作ってやったぜ!と勢い込んでお客さんにシングルサインオンができたところを見せて、何の反応もなかったのはとてもやるせない気になった。。JWTトークンとかいろんな情報乗ってて楽しいんだけどなぁ。

知らなかった、時に困るWebサービスのセキュリティ対策

ペパボで発生したセキュリティインシデントの話し。淡々と丁寧な話し方をされるというのも相まってすごい生々しくてリアルだった。。
質問でもあったけどあとからセキュリティのフレームワークを導入するのってすごい大変だと思うから、ある程度の企業規模になったらセキュリティエンジニアみたいなものはちゃんとポジションとして用意しておかないといけないんだろうな。

実録!ある担当者がみた「謎ガジェット」開発1年史

電子名札のセッション。みんな光物が大好き!

JavaCardの世界

ベストスピーカー1位のセッション。
SIMカードで使われている実装の話しということで、全く知らない領域だったけど、実装できそうな気になった()
最後のSIMに書き込むときはキーが必要でその発行は個人では厳しいという落ちは面白かった。途中からなんとなくそうだろうなぁとは思ってたけどw

Envoy externals and ideas

Envoy というサービスメッシュを構成するときのサービスのお話し。最近 k8s 触ってるので一緒に触ってみよう。

2日目

高集積コンテナホスティングにおけるボトルネックとその解法

前職 LXC を使っていたこともあり、トラシューは同じ感じでやっていたので完全に新しい知見かというとそうではなかったけど、ただその方法やカーネルの実装がすごく丁寧に解説されていてとても分かりやすかった。

ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ

マネージドなSaaS/PaaS系のサービスでピタゴラスイッチを作って Let's Encrypt の証明書を発行するという実装方法の解説。ピタゴラスイッチするときってどこまでサーバーレスにするかというのが考えどころだと思うけど、その辺が非常に参考になるアーキテクチャーだった。

Webアプリケーションエンジニアが知るべきDNSの基本

DNS の仕組みがとても分かりやすかった。強いえて言えばもう少し経験からくる部分があるとよかったかなと思った。
質問で、負荷とか加味してTTLどれくらいにしますかというないようで、普段は300、移行のときは10というのを聞いてそんな感覚でも大丈夫なんだというのは知見だった。

RDB THE Right Way ~壮大なるRDBリファクタリング物語~

DB のリファクタリングの勘所がわかった。もう一回動画見なおそうと思う。
そしてSQLアンチパターンとDBの設計の本は買おうと思う。

さいごに

最初スポンサーチケットを買って、そのあと譲渡してスピーカーチケットに切り替えた。スピーカーチケットで電子名札がもらえるかと思ったらそうではなかったのでちゃんと確認しておけばよかった。。
クロージングで牧さんが話されたコミュニティのエコーチェンバー現象というのは初めて知った。いろいろ思い当たる節があったのがクリアになった気がした。最後の最後まで知見が得られるのはさすが builderscon感あった。
そういえば今年は前回に増して人が多くなってた気がした。セッションに行こうとしたら満員御礼の紙が貼ってあってもう入れない、という状況があった。スタッフの人に聞くと場所が最初に決まるらしいので、想像以上に多くなると立ち見や入れない人が増えそう。
追記:この辺はこういうことらしい↓
https://twitter.com/lestrrat/status/1038708506847662080?s=21

毎度だけど改めて今年の builderscon も最高だった。来年もぜひ参加したい。

builderscon tokyo 2017 に行ってきた & Azure について LT してみた

最近ブログを書くきっかけが YAPC に行くことになっていて、もうちょっと活用したいなぁと思っております。
ということで、builderscon tokyo 2017 に行ってきました。

2016 にも参加しようと思ったのですが、チケットがすぐになくなってしまって参加できなかったので、初 bulderscon になります。
buildersconは「知らなかった、を聞く」というテーマなので、今回は敢えて自分の仕事やこれまでの経験にない分野のセッションを聞いてみました。
ということで特に気になったセッション。

DeepLearningによるアイドル顔識別を支える技術

twitter とかでバズっていて、アイドルはあまり興味がないのでへーと思ってみていただけだったのですが、それを実現するための技術のセッションです。
ちょうど深層学習に興味があり、勉強始めていたところだったので、出てくる用語もちらほらわかるものがありました。
特に、集めた顔画像から、パラメーターをもとにして適当に別の顔を作り出すというのは非常に興味深かったです。
次に紹介するセッションもですが、画像分析・深層学習はアルゴリズムが特に肝になってくる分野なんだなというのが実感出来ました。

builderscon.io
speakerdeck.com

マイクロチームでの高速な新規開発を支える開発・分析基盤

Gunosy のエンジニアの方の発表です。LUCRA という キュレーションアプリの開発時の体験談です。
個人的に参考になったのは、3ヶ月間での開発期間という中でのチーム編成でした。
私の過去の経験で、新しいプロダクトを短期間で開発する時は、どうしてもメンバーのスキルに依存してしまい、頓挫することも少なくないですが、持っていないスキルでを習得するというモチベーションで取り掛かるというのは非常に重要なことだと思いました。
もはや死語かもしれませんが、やっぱりフルスタックなエンジニアは必要です。

あとは分析基盤の専門チームがいるという話しや、絶対に数字以外を根拠としないというポリシーなど、なるほど。。と感心ばかりしてました。
https://builderscon.io/tokyo/2017/session/f80aad32-4f21-11e7-aa42-42010af00d0abuilderscon.io
speakerdeck.com

知られざる世界 〜WEB以外のPHP

WEB 以外でも PHP を使えるんだよという啓蒙セッション(?)です。
uzulla さんのトークはやっぱり面白いですね。
私は、WEB 開発はPHPから入ったので、PHP = WEB という概念がありましたが、ベータ的な扱いとは言えまさかモバイルアプリの開発もできるとは思いませんでした。
自分の中では、PHP 5 で止まっているので、PHP 7 にアップグレードしないといけないですね。。

builderscon.io
speakerdeck.com

今日から使えるCSS Grid

フロントエンドをバリバリやっているわけではないので、コアなフロントエンドネタにはついていけないなぁと思っていたのですが、CSS の新しい機能ということでそれほどコアではなく敷居も低いかなと思い聞いてみました。
プレゼンもわかりやすく、デモもあって、非常に勉強になりました。
まさかもう無いかと思いますが、テーブルでのレイアウトや、あとは float/position を使ってのレイアウトはすごくめんどくさいイメージがあるのですが、それらと比べると CSS Grid ははるかに使いやすいですね。
CSS 標準というのもいいです。
たまに趣味でウェブアプリ作ることがあるので使ってみようと思います。
builderscon.io

スライド
今日から使えるCSS Grid

ランチセッション

お昼を食べながらのPRセッションです。
サイボウズの kintone は名前は知っていたのですが実際動きを見るのは初めてでした。
もし今後グループウェア使うことになったら使ってみたいなぁと思いました。
正直なところ、弊社SharePoint 負けてる気が。。

WEB+DB PRESS 100号記念 特別企画

WEB+DB PRESS 編集長と、Ruby高橋メソッド で有名な高橋 征義さんのパネルディスカッションです。
いろいろこれまでの裏が聞けて面白かったですね。
WEB+DB PRESS の定期購読を始めてしまいましたw

Azure について LT してみた

そして、LTです。まさか採用されるとは思っていなかったのですが、初LTをしてしまいました。
思ったよりもはるかに時間が短く、話したかったことがほとんど話せず、やっぱりLTはセンスが必要なんだなと感じました。。
黒歴史になりそうなのでLTの動画公開がなければいいのにと思っています。。

私が話した内容ですが、Azure について、でした。
YAPC含め今回の度のセッションを参加しても、Azure というキーワードを一度も(Cognitiveはすこしあったものの。。)聞いておらず、
オープンソース界隈の方々のなかでは、どのくらい Azure は浸透しているんだろうというが非常に興味があったので話してみました。

スライドタイトルが出た時点で乾いた笑いが出ていたのであーそんな感じなのかorzとなっていたのですが、
通してもやっぱり Azure って。。という雰囲気を感じました。

今回のLTの最大の目的であったアンケートの結果がこちらです。
https://1drv.ms/x/s!AscFEgIsD0TWg6xa6pAeiLcWs-Sktg

Microsoft が嫌いというどうすることもできない理由はおいておいて、大人の事情やAWSを使っているからというのもちらほらありますね。
仕事でお客さんのところに行っても、AWS 使ってるからという理由は結構あってそういうところに Azure を使ってもらうのは厳しいケースが多いです。
他のクラウドに対してサービスが劣っているというのは特に無いと思っているので、先に始めたというのはやっぱり強いです。


この LT で一番言いたかったのは、Azure が優れている、AWS が優れている、ということではなくて、
Azure を知ってもらって、皆さんのサービス開発をより良いものにしてもらいたいということでした。
※私も過去そうでしたが、オープンソース界隈の方々はMSに対するアレルギーを感じるので、そこに対して何かしらアプローチ出来たらなぁとも思っています。
※逆に社員含め、MSテクノロジー界隈の方々がなぜこういうイベントに行かないのか(あくまでtwitterやブログ見て感じてるだけですが)というのも疑問があります。

まとめ

過去の YAPC からずっと参加していていますが、やっぱり面白いです。何かを作りたくなる気になります。
builderscon(主催者牧さん?)のコンセプトが非常に良いです。こういうカンファレンス・イベントがもっと増えればいいなぁと思いました。
今回 LT でちゃんとお伝えできなかったことを伝えたいので、来年は、セッションで参加したいと思います。
(今年は気づいたら募集が終わっていた。。)