2021年11月10日と11日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2021」がオンラインで開催されました。そこで齋藤氏と尾野氏が「LINEデータプラットフォームにおけるApache Icebergの導入」というテーマで、データ処理とデータのインジェスチョンパイプラインについて紹介しました。まずはLINEで実施しているデータ処理について。 自己紹介と発表前半のアジェンダ 齋藤智之氏：LINE Data Platform室の齋藤智之です。現在私は、データプラットフォーム開発組織のシニアソフトウェアエンジニアとして、研究開発や開発プロジェクトのリードをしています。今日の発表では、データプラットフォームを開発運用する中で直面してきた課題と、その解決に向けた取り組みの一部を紹介しようと思います。 発表は前半と後半の2部に分かれて
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。データ統括本部でYahoo!広告のデータエンジニアをしている江島です。 本記事では、Yahoo!広告のデータ分析環境であるデータレイク上のデータを、Apache Hudi を用いてレコード単位で削除可能にした事例を紹介します。 Yahoo!広告のデータ分析環境 Yahoo!広告における データマーケティングソリューション では、ヤフーの持つ圧倒的な量と質のデータを活用し、消費者理解や広告効果分析を目的としたさまざまな商品を提供しています。 これらの商品を提供するための裏側には広告に関する膨大なログや多種多様なサービスのログを使ってデータ分析や機械学習を行うためのデータ基盤が必要です。データマーケティングソリューションで
普段Webサーバを運用していて、めんどくさいトラブルのひとつに「Segmentation fault」があります。 あれー？なんか500エラーがでるなーなんて思ってログを見るとSegmentation faultになってるときは死にたくなります。 そもそもSegmentation faultはメモリ上にあるデータに対して不正が行われたときに起こるもので、 インフラエンジニアにとってはなかなか手がだせないところでもあります。 それでもなんとかして治さないといけないわけなので せめてどのプログラムが悪さしてるかどうかぐらいは調べ上げてみます。 apacheでのログ apache + mod_perl での環境です。 こんな感じでエラーがでます。 #tail error_log [notice] child pid 26028 exit signal Segmentation fault (11
※ 2018/6/25 assetについて追記しました。 目的 https://qiita.com/darum/items/b4841e031dca46b8c138 こちらで作った環境を使って、以下のようなアドレスでLaravelアプリにアクセスするように設定を行う アドレス http://192.168.1.10/laraapp/ ※ 自宅環境なので、DNSなしです 前提条件 Laravbelアプリは出来上がっている（完成といかなくても、ローカルで動作確認済み） 事前作業 /home/me/laravel にデプロイ済み ※ モダンなデプロイ方法はいっぱいあると思いますが、こちらについては別途 作業 Apache2.4 の設定
LinuxでApacheのAliasを設定して複数のサイトを公開する LinuxでApacheをインストールすると、デフォルトのDocumentRootは以下の場所になります。 /var/www/html ただし、これだと1つのWEBサーバーに対して1つのサイトしか公開... サブドメインじゃダメなの？と思った方へ。 まず、この記事に至った経緯ですが、自宅サーバーでフリードメインのサブドメインを自分で設定しようとすると何かと面倒なのでした。 しかし、この方法だと比較的簡単に設定することができます。 それでは参ります！ Laravelをサブディレクトリで動かす 作成または変更する設定ファイルは、サーバー側でAriasを設定する〜.confと、Laravelのpublicディレクトリ直下にある.htaccessのみです。 ApacheのAliasを設定する ここでは、Linux（CentOS
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 これまでのApache2.2系以前でのアクセス制御の書き方は賛否両論でした。僕はあまり好きじゃありませんでした。 過去のアクセス制御に関しては、以下の記事がとてもわかりやすくまとめられていると思います。 こせきの技術日記 – Apacheのアクセス制御をちゃんと理解する。 ここで、以下のように言及されています。 こんなバッドノウハウ、本当はどうでもいいと思う。Apache 3.0では、かっこいいDSL(VCL)で書けるようにする構想があるらしいのでがんばってほしい。 ということで、2.4系ではDSLとはいかないまでも、Require*というディレクティブを使ったモダンな書き方ができるようになったので、それを2.2系以前のアクセス制御の記述と比
こんにちは。望月です。 Apacheやnginxとアプリケーションサーバを組み合わせてシステムを構成するのは、オンプレでもAWSでもよくあるパターンです。AWSでそのシステムを実現しようとすると、ELB + EC2という構成が定石ですが、ELBがWebサーバのフロントに立つことによりEC2単独で動作させる時と比較すると挙動が異なるところもあります。 例えばWebサーバから見たアクセス元のIPアドレスが変わってしまうことです。本来の送信元IPアドレスがロードバランサのプライベートIPアドレスに変わり、本来の送信元IPアドレスはX-Forwarded-Forヘッダの末尾へと格納されます。X-Forwarded-ForはRFCに記載された正式な仕様ではありませんが、プロキシやロードバランサでは一般的に利用されるデファクトスタンダードとなっています。 ELB配下でのアクセス制御 さて、以下のような
SSLProxy を使っている Apache を2.2から2.4にバージョンアップした際にトラブルが発生したので概要と対処方法をメモ。 CentOS5 の Apache-2.2 で下記のような Proxy の設定をしているサーバーがありました。 Proxy の部分の設定は下記のような感じ。 (省略) SSLProxyMachineCertificateFile /etc/httpd/conf/ssl.crt/test.pem (省略) RewriteEngine On RewriteRule ^/test/(.*) https://192.168.0.1:9443/test/$1 [P] ProxyPassReverse /test/ https://192.168.0.1:9443/test/ (省略) CentOS5 の EOL を間もなく迎えるため、CentOS7 のサーバーにリプレ
JPCERTコーディネーションセンター(Japan Computer Emergency Response Team Coordination Center:JPCERT/CC)は3月27日、「Japan Vulnerability Notes(JVN)」に掲載した記事「JVNVU#95818180: Apache HTTP Web Server 2.4 における複数の脆弱性に対するアップデート」において、Apache HTTP Web Server 2.4の脆弱性について伝えた。 脆弱性の影響を受けるプロダクトおよびバージョンは次のとおり。 Apache HTTP Web Server 2.4.33よりも前のバージョン JVNVU#95818180 - Apache HTTP Web Server 2.4 における複数の脆弱性に対するアップデート 上記のバージョンでは、7つの脆弱性(CV
ATS（App Transport Security）は、iOS 9.0 や OS X 10.11以上で導入された、セキュリティ機能です。この機能により、アプリとWEBサービス間の接続のプライバシーと、データの整合性を向上させることができます。ATS が有効なアプリは HTTP を使った通信ができないため、WEBサーバには HTTPS が必須になります。加えて、TLSのバージョンや、暗号化スイート等も Apple が指定するものを設定しなければ、アプリからWEBサーバに接続することができません。そこで今回は、WEBサーバの Apache を ATS（App Transport Security）に対応する方法を調べてみました。 ATS に対応するための要件 ATS が有効なアプリと WEBサーバが接続できるようにするための要件は、iOS Developer Library「Requirem
Mozilla SSL Configuration Generator Redirecting to the updated SSL Configuration Generator…
外部から簡単にHTTP_PROXYという環境変数がセットでき、サーバ間通信や外部サイトと連携している場合に影響があるかもしれない脆弱性です。(HTTPoxy. CVE-2016-5385) PHPの場合はphp-fpm, mod_php, Guzzle4以上やいくつかのライブラリで影響あります。 対応方法は簡単です。 Apache側で対応する場合は、mod_headerを使える状況であれば、confファイルに下記の1行を追加。 RequestHeader unset Proxy FastCGIの場合は下記の1行を追加。 fastcgi_param HTTP_PROXY ""; Guzzleは6.2.1で対応されたようです。 Release 6.2.1 release · guzzle/guzzle · GitHub コミットログを見ると、CLIの時のみ、getenv('HTTP_PROXY
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
